Updated the Infusion Browser support chart

[Colin Clark]

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