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.
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Brooks newton
> Sent: Wednesday, February 10, 2016 12:34 PM
> To: <EMAIL REMOVED>
> Subject: [WebAIM] Recommending Widget Markup that Doesn't Work in Reality
>
> Hi Folks,
>
> Here are a few questions for the Web accessibility experts who are in positions to recommend advice to Web site production teams that are ready to take action to build out pages for launch.
>
> Do you recommend ARIA-enabled solutions for complex widgets, when you know full and well that there is no combination of OS, browser and assistive technology that will render the particular widget accessible, in terms of actual performance? If so, wouldn't everyone agree that it is imperative to communicate the fact that a proposed solution is "theoretically sound," yet functionally inaccessible given the current state of software?
>
> Over the years I've seen a lot of theoretical solutions that pass WCAG compliance muster, which would in no way pass a more stringent standard, such as the performance objectives central to standards like the Twenty First Century Communications and Video Accessibility Act (CVAA).
>
> Do any accessibility experts out there ever tell their clients that some design patterns are inherently inaccessible, given the current state of technology? If this is the case, do you recommend an alternate, fully accessible version of the inherently inaccessible widget or content? Or, is the better advice to simply give up on the fancy widget for now and stick with old school accessible techniques to present the same content to users so all abilities?
>
> Last question: Why don't we have an accessible, freely available centralized repository of fully vetted ARIA design patterns, with a full compatibility matrix that displays OS, browser, AT, etc. compatibility? Are the competitive pressures between companies /agencies keeping us from reaching a consensus on what advanced cookbook solutions work now and which theoretical models need additional support before we can recommend with confidence to clients?
>
>
> Brooks Newton
>
>
> Sent from my iPad
>
>> On Feb 10, 2016, at 12:20 PM, <EMAIL REMOVED> wrote:
>>
>> Send WebAIM-Forum mailing list submissions to
>> <EMAIL REMOVED>
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://list.webaim.org/mailman/listinfo/webaim-forum
>> or, via email, send a message with subject or body 'help' to
>> <EMAIL REMOVED>
>>
>> You can reach the person managing the list at
>> <EMAIL REMOVED>
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of WebAIM-Forum digest..."
>> Today's Topics:
>>
>> 1. Re: Accessibility Testing Tools that Work on a Screen Reader?
>> (Jared Smith)
>> 2. Re: JAWS 15 Vs JAWS 16 (Carousel widget example) (Robert Fentress)
>> 3. Re: here is a peace about access in education I wrote
>> (John E. Brandt)
>> 4. Re: Accessible SharePoint (Andrews, David B (DEED)) 5. Re: JAWS
>> 15 Vs JAWS 16 (Carousel widget example) (Jonathan Avila) 6. Re:
>> Accessibility Testing Tools that Work on a Screen Reader?
>> (Jonathan Avila)
>> 7. Re: JAWS 15 Vs JAWS 16 (Carousel widget example) (Robert Fentress)
>> 8. Re: JAWS 15 Vs JAWS 16 (Carousel widget example) (Bryan Garaventa)
>> 9. Re: JAWS 15 Vs JAWS 16 (Carousel widget example) (Jonathan Avila)
>> 10. Re: JAWS 15 Vs JAWS 16 (Carousel widget example) (Detlev Fischer)
>> 11. Re: Accessibility Testing Tools that Work on a Screen Reader?
>> (Sean Murphy)
>> 12. Best method of hiding text based upon a answer. (Sean Murphy) 13.
>> Re: screen reader usage? (Sean Murphy) 14. Re: JAWS 15 Vs JAWS 16
>> (Carousel widget example) (Jonathan Avila) 15. Re: Activating controls
>> with hidden accessible names using
>> speech recognition (Robert Fentress) 16. Re: Activating controls
>> with hidden accessible names using
>> speech recognition (_mallory)
>> 17. Re: JAWS 15 Vs JAWS 16 (Carousel widget example) (Robert Fentress)
>> 18. Lift Assistive (Thompson, Rachel) 19. Re: Lift Assistive (Jonathan
>> Avila) <mime-attachment> <mime-attachment> <mime-attachment>
>> <mime-attachment> <mime-attachment> <mime-attachment>
>> <mime-attachment> <mime-attachment> <mime-attachment>
>> <mime-attachment> <mime-attachment> <mime-attachment>
>> <mime-attachment> <mime-attachment> <mime-attachment>
>> <mime-attachment> <mime-attachment> <mime-attachment>
>> <mime-attachment> >> >> archives at http://webaim.org/discussion/archives
>> > > > >
>