WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Recommending Widget Markup that Doesn't Work in Reality

for

From: Brooks newton
Date: Feb 12, 2016 5:02PM

Hi Matt,

I appreciate your thoughtful response and call to action. I think a publicly available set of official widget examples would go a long way toward getting consensus, not only from the accessible development community, but also from software manufacturers whose products must support, in an interoperable fashion, the intended user interaction.

I'm looking forward to the ARIA 1.1 Authoring Guide, as well as a user friendly mechanism to harness ideas from the larger community. I know I've had thoughts about new roles and states I would make standard if I were king for a day, and I'm sure many others on this list have ideas to add to the mix, as well.

Thanks for your sharing your perspective and for providing an update on the positive progress that's underway.

Brooks Newton

> On Feb 12, 2016, at 11:24 AM, Matt King < <EMAIL REMOVED> > wrote:
>
> Hi Brooks,
>
> I feel your pain ... the situation sometimes feels way beyond frustrating.
>
> I strongly believe ARIA is promising, and perhaps one of the most important accessibility technologies we have. But, industry understanding of ARIA and the quality of its implementation is in a place similar to where browsers stood relative to standards in the 90's and early 00's. Back then, getting 2 browsers to work in a reasonably consistent manner was similarly frustrating. ARIA is young and still has a lot of maturing to do.
>
> Especially as someone who is blind, and who just this morning hit a literal impasse trying to make an Amtrak reservation (step 2 in their wizard where they offer hotels and cars does not have an accessible path forward if you don't want a car or hotel), I couldn't agree more that we need to be practical when delivering solutions where broadly available functionality is essential. That may occasionally mean using a tried and tested web 1.0-like approach.
>
> However, I think we also need to push the envelope, in real world apps not just test sites, whenever feasible. If we aren't willing to innovate and experiment, people with disabilities could get stuck in some web 1.0 state and end up more isolated and excluded, falling deeper into separate and not equal.
>
> In practice, I've not usually found that quirks in properly coded ARIA widgets create absolute road blocks. Generally, they just create little annoyances. So, experimenting is often not very risky. You need to make a judgment as to whether or not the specific quirk you find is likely to cause a novice assistive technology user to abandon the task.
>
> As you pointed out, one shortcoming of ARIA 1.0 is that the authoring practices guide was never completed. So the reference implementations you inquired about ... well, they never appeared. In fact, the ARIA 1.0 draft guide referenced external examples. The web moved on, some examples evaporated, others changed to an inaccessible state, and readers of the draft were left confused. They had to piece together the best understanding they could from a guide that never had consensus agreement as to whether it accurately represents the ARIA specification and acceptable best practice.
>
> Nevertheless, everyone involved in getting ARIA 1.0 out the door was doing their best. It was a massive effort. Given resources and the intense need for the standard, finalizing ARIA 1.0 without a complete guide was certainly what needed to be done.
>
> Last year, James Nurthen and I agreed to co-chair a taskforce that would take on the challenge of an ARIA 1.1 authoring practices guide. So, a good chunk of what you are asking for is on the way.
>
> The ARIA 1.1 guide has code examples at its core. Instead of being a reference, the examples are the center-piece. They will be written in vanilla HTML/JS/CSS without any external dependencies. The design will facilitate easy consumption and reuse. They will demonstrate best practice and will demonstrate all ARIA 1.1 features.
>
> We are testing them, but there will not be a published test matrix. As Alastair described, we would never finish and it would be outdated before we finished it. That said, there are separate testing efforts on-going, and the guide will reference that work.
>
> We welcome more participants in this work. There are 2 ways to help:
> 1. Join W3C and join the ARIA working group, then volunteer for the APG taskforce.
> 2. Contribute example code.
>
> If you are not in a position to join W3C, but could claim an example coding task that is up for grabs, that would be tremendously valuable. Even contributing a single example would be appreciated. You then would get the benefit, I hope it would be thought of as a benefit, of a peer review with the taskforce.
>
> As I write this, while it is all in GIT and we do have an example template, we have not made it easy for anyone who is not part of the taskforce to just jump in and claim a task. We do all the task planning in meetings right now.
>
> In the meantime, if anyone on this list would like to help, just drop me a note. If there is interest, I'll work out a way to manage it.
>
> Matt King
>
> PS, I ended up using the Amtrak 800 number and voice system to make my reservation. It's nice, but I would have preferred the web; it would have been faster if it were accessible. So ironic the accessibility errors are not on stuff that doesn't matter instead of critical elements like the add to cart button and next button in the reservation wizard.
>
>