Updated the Infusion Browser support chart

Jan Richards jan.richards at utoronto.ca
Fri Jan 29 21:40:43 UTC 2010


Hi all,

I'm late coming to this, but I unfortunately don't have the cycles to 
read the Fluid list. :( Maybe I can be cc'd on this thread?

I just have two things to add:

- re: (1) and (2): in ATAG 2.0 there is a similar author-dependency 
issue - so you do the best you can up to the point where the "author(s) 
might set less strict preferences, ignore prompts for accessibility 
information, provide faulty accessibility information, write their own 
automated scripts, etc."

- re: (3): it would be nice to validate things on at least one screen 
reader on one browser on one platform. e.g., by a screen reader in the 
Fluid community, user testing as part of AEGIS project, etc.

Cheers,
Jan




Justin Obara wrote:
> Armin, Alison and I will be meeting today to start working on this. Jira's will likely be showing up shortly.
> 
> Thanks
> Justin
> On 2010-01-06, at 1:22 PM, Jess Mitchell wrote:
> 
>> All,
>>
>> This is a great discussion and I think really timely and important work.  Alison, Armin, and Justin perhaps you can coordinate a plan of attack starting with filing a jira?
>>
>> Best,
>> Jess
>>
>>
>> On Jan 5, 2010, at 2:27 PM, Alison Benjamin wrote:
>>
>>> Hi, 
>>>
>>> A heterogeneous bunch will be integrating components into their webpages, and some will be from organizations obliged to adhere to various a11y standards. From their perspective, they will want to know where components stand vis a vis these regulations. And of course, as Colin points out, the context of use where components are integrated, and an integrator's development choices, are out of our hands. From our end, I agree that the 4 steps Justin outlined will be good. 
>>>
>>> WRT: 
>>>
>>>>> 3) At this point, assume that proper development techniques will yield AT support (with exceptions listed below)
>>>>>
>>>>> For the cases where "proper" is clearly quantifiable, +1. This part will still be a challenge.
>>>>>
>>>>> In the other cases, we'll have to continue to work towards change and improvement in ARIA and other essential technologies.
>>>>>
>>> I agree this is a challenge! And I think there will always be those developers and designers who have the goal of achieving platform accessibility (e.g. to a specific AT). Through user testing, some platform a11y issues will come up. In these cases, if we're not able to address issues with WCAG & ARIA, we can document the exceptions if they arise. Is that what you guys mean by  3) ?
>>>
>>> What's the best way to communicate Fluid's affordances for good UX and accessibility to Fluid users? Many will want to know the 4 dimensions Justin covered. Armin, is this what we're imagining the a11y page will be for? Or does it make sense to integrate into existing documentation? 
>>>
>>> re: 2) I can help write test plans for components based on WCAG2. Can I go ahead and create Jira tickets for this? 
>>>
>>> Thanks, 
>>> Alison 
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Jan 5, 2010, at 11:24 AM, Justin Obara wrote:
>>>
>>>> Thanks everyone for the feedback.
>>>>
>>>> Armin, thanks for the help.  Do you know when will you might have some time to start looking at this?
>>>>
>>>> We'll have to make sure to address Colin's points as we go along, too.
>>>>
>>>> Thanks
>>>> Justin
>>>>
>>>> On 2010-01-04, at 12:17 PM, Armin Krauss wrote:
>>>>
>>>>> Justin,
>>>>>
>>>>> great email and suggestions. I agree with all of your suggestions and would be happy
>>>>> to help to create test plans based on WCAG 2.0 or to create profiles and test scenarios
>>>>> for screen readers.
>>>>>
>>>>> Armin
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jan 4, 2010 at 12:01, Colin Clark <colinbdclark at gmail.com> wrote:
>>>>> Hi Justin,
>>>>>
>>>>> Really thoughtful response. Some comments inline.
>>>>>
>>>>>
>>>>> On 24-Dec-09, at 10:29 AM, Justin Obara wrote:
>>>>>
>>>>> I've been doing some more thinking about that a11y testing stuff that Armin brought up a while ago.  (Sorry that this is so late coming.)
>>>>>
>>>>> Maybe what we could do is to make test plans based on wcag 2.0.
>>>>>
>>>>> I gather from being part of a conversation with Jan, the other day, that wcag 2.0 will be legislated in some manner.
>>>>>
>>>>> I think WCAG 2 is pretty sensible as far as accessibility standards go. As you say, it is inevitably going to form the basis for a lot of updated international legislation. It's also general and conceptual enough to enable design flexibility and a layered approach. That said, this general-ness will also be something we struggle with a bit as we create those WCAG 2-compliant test plans for Infusion.
>>>>>
>>>>>
>>>>> What I'm imaging we could do, is to indicate what level (A, AA, or AAA) each component complies with in it's base configuration, or is possible to achieve.
>>>>>
>>>>> For example the video player is capable of display captions, but it is up to the integrator to supply them.
>>>>>
>>>>> This distinction makes a lot of sense. Out of the box, we ship at a certain level of compliance, but clearly a user's integration choices--as well as their content--will affect accessibility either positively or negatively. Articulating some of these choices will help implementers understand accessibility better, too. I can imagine that Armin and Alison's a11y page would be useful for discussing these sorts of issues.
>>>>>
>>>>>
>>>>> Here are a couple critiques of wcag 2.0 (they are both from 2006 though)
>>>>> http://www.alistapart.com/articles/tohellwithwcag2
>>>>> http://www.webcredible.co.uk/user-friendly-resources/web-accessibility/wcag-guidelines-20.shtml
>>>>>
>>>>> There were lots of controversies surrounding WCAG 2 as it was being developed; standards like this can be really tough to have complete consensus on. There's always a grain of salt or two to take with Joe Clark's criticisms of WCAG, but there are some interesting points here, too. I'm particularly keen to look more into some of the issues around off-screen positioning and CSS layouts.
>>>>>
>>>>>
>>>>> We are still faced with an issue of what AT's to test with. In looking at the builder, we found that putting the text of a button inside of a span, caused the button to only announce "Button" in NVDA. However, if you changed to focus mode, it did read it properly. This leads me to believe that to some degree AT's are essentially broken, or at least not fully functional at the moment.
>>>>>
>>>>> That's the same conclusion I've come to as well. Everett seemed to agree, but I hesitate to say it definitively, since I'm not actually an AT user myself.
>>>>>
>>>>> Writing a screen reader isn't a trivial task, and technology is changing so fast. But I can't shake the feeling that a lot of the existing crop of products haven't successfully embraced the Web and its evolving interaction idioms. With NVDA and Orca, I hope the open source world has a chance to rethink usability for screen reader users over the long run.
>>>>>
>>>>>
>>>>> It seems to me that wcag 2.0 will allow us to say, for example, if the aria semantics are correct, then we are compliant whether or not the AT's actually work properly. I'm not quite sure this is correct and it is a poor approach at best. However, it will prevent us from getting into a situation where we are making vain attempts at implementing concessions for a variety of AT's.
>>>>>
>>>>> Yeah, I think that's exactly right. We want our stuff to work amazingly and be super easy to use for a whole variety of users. Our start on that is to create an open architecture, use great semantic markup, and ensure we're following the latest and best techniques like ARIA.
>>>>>
>>>>> Beyond that, we still have to take advantage of useful workarounds, as well as progressive enhancement, to make the day-to-day experience of using Infusion better.
>>>>>
>>>>>
>>>>> So here is my suggestion.
>>>>>
>>>>> 1) Make test plans based on wcag 2.0 and aim to have every component ship with defaults which are at least AA and include options which ensure integrators can achieve at least AA compliance.
>>>>>
>>>>> +1.
>>>>>
>>>>>
>>>>> 2) Indicate some how, which level of compliance each component meets
>>>>>
>>>>> Also +1, assuming we also outline some of the considerations an implementer should take into account when using our components.
>>>>>
>>>>>
>>>>> 3) At this point, assume that proper development techniques will yield AT support (with exceptions listed below)
>>>>>
>>>>> For the cases where "proper" is clearly quantifiable, +1. This part will still be a challenge.
>>>>>
>>>>> In the other cases, we'll have to continue to work towards change and improvement in ARIA and other essential technologies.
>>>>>
>>>>>
>>>>> 4) Continue testing keyboard a11y in A-grade browsers
>>>>>
>>>>> +1.
>>>>>
>>>>> Thoughts? Comments?
>>>>>
>>>>> Colin
>>>>>
>>>>>
>>>>> ---
>>>>> Colin Clark
>>>>> Technical Lead, Fluid Project
>>>>> http://fluidproject.org
>>>>>
>>>>>
>>>> _______________________________________________________
>>>> fluid-work mailing list - fluid-work at fluidproject.org
>>>> To unsubscribe, change settings or access archives,
>>>> see http://fluidproject.org/mailman/listinfo/fluid-work
>>> _______________________________________________________
>>> fluid-work mailing list - fluid-work at fluidproject.org
>>> To unsubscribe, change settings or access archives,
>>> see http://fluidproject.org/mailman/listinfo/fluid-work
> 
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work

-- 
(Mr) Jan Richards, M.Sc.
jan.richards at utoronto.ca | 416-946-7060

Adaptive Technology Resource Centre (ATRC)
Faculty of Information | University of Toronto



More information about the fluid-work mailing list