Updated the Infusion Browser support chart

Thu Jan 7 20:26:18 UTC 2010

Hi,
I created a bunch of Jira tasks to address integrating WCAG our QA  
testing, assigning them to myself & Armin.
We will ping the list as issues arise/for feedback and as we complete  
the tasks.

Image Reorderer
http://issues.fluidproject.org/browse/FLUID-3464

Layout Reorderer
http://issues.fluidproject.org/browse/FLUID-3467

Builder
http://issues.fluidproject.org/browse/FLUID-3465

Inline Edit
http://issues.fluidproject.org/browse/FLUID-3466

Pager
http://issues.fluidproject.org/browse/FLUID-3468

Progress
http://issues.fluidproject.org/browse/FLUID-3469

sortable jQuery tabs & sortable vertical list
http://issues.fluidproject.org/browse/FLUID-3470

UI Options
http://issues.fluidproject.org/browse/FLUID-3471

Uploader
http://issues.fluidproject.org/browse/FLUID-3472

Thanks,
Alison

On Jan 6, 2010, 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
>