E-mail List Archives

You are here: Home > Community > E-mail List Archives > View Thread

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

Number of posts in this thread: 10 (In chronological order)

From: Brooks newton
Date: Wed, Feb 10 2016 1:34PM
Subject: Recommending Widget Markup that Doesn't Work in Reality
No previous message | Next message →

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 ADDRESS REMOVED = wrote:
>
> Send WebAIM-Forum mailing list submissions to
> = EMAIL ADDRESS 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 ADDRESS REMOVED =
>
> You can reach the person managing the list at
> = EMAIL ADDRESS 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>
> > > >

From: _mallory
Date: Wed, Feb 10 2016 2:31PM
Subject: Re: Recommending Widget Markup that Doesn't Work in Reality
← Previous message | Next message →

I'm in this conundrum right now (not as an accessibility expert, but
as someone who complained an article about a Web Component on a
popular publisher's site didn't have basic keyboardability, which is
totally doable). The widget is sufficiently deviant from the closest
aria-practices model (combobox) that the recommendations are sketchy
at best, and when the developer is done building it, I won't be
surprised to find it doesn't work, or only sorta half-works in a single
SR-browser combo, doesn't work in Dragon at all, etc.

And no, I have no idea what to do but I am keen to tell the dev that
he's going into bleeding-edge area.

He's basically going to be building a broken widget, then writing an
article about how to build that broken widget, and there's not
much we can do right now about it. That really bugs me. People are using
the New Hotnesses before browsers and AT really catch up with them.

There's also the fact that lots of users don't know the magic keystrokes
prescribed by ARIA anyway-- so something can be both theoretically
possible, and practically buildable, but users still can't use it.

I don't know the solution to that either, other than written
instructions before each funky new widget.

I've been fighting React recently so was searching for others who'd
gone further with accessible widgets and ran into this:
http://davidtheclark.com/building-react-aria-menubutton/

quote:
"Accessibility is Hard. Don't let anybody tell you otherwise. Yes, yes, yes, I know, of course, you're right, absolutely â there are indeed some very simple, elementary best-practices that do affect accessibility (e.g. use alt text! semantic tags! colors with sufficient contrast!). And if that's all you're worried about, then yes, accessibility is easy. But pass beyond those basics, try to build something sufficiently complex with JS interactivity, and (unless your experience is dramatically different from mine) your research will lead you into a baffling hodgepodge of incomplete, contradictory, insufficiently exemplified, inadequately verified, usually outdated material."

I've heard basically this from several other devs-- we can't tell if
it's broken because it only works theoretically, or because we Googled
some older version of a spec, or if we're just waiting for a JAWS
update, or what.

And I suspect a lot of developers, with deadlines and demands and the
such, will just figure they'll build to whatever spec they find, as
best they could understand it, and leave it until whenever that bit
of code needs refactoring or something. So it could sit out there for
ages, not updated. Who knows.

> 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?
>
It would be ideal if the ARIA authoring pages had these, and they
started with some initial links to open ajax and other demo links.
These need updating, but some widgets (like tab panel, slider,
modal dialog) have gotten pretty stable and have lots of examples
elsewhere. It would be good to have the best of those referenced
in the docs.

_mallory

On Wed, Feb 10, 2016 at 02:34:00PM -0600, Brooks newton wrote:
> 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 ADDRESS REMOVED = wrote:
> >
> > Send WebAIM-Forum mailing list submissions to
> > = EMAIL ADDRESS 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 ADDRESS REMOVED =
> >
> > You can reach the person managing the list at
> > = EMAIL ADDRESS 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>
> > > > > > > > > > > >

From: Alastair Campbell
Date: Thu, Feb 11 2016 2:51AM
Subject: Re: Recommending Widget Markup that Doesn't Work in Reality
← Previous message | Next message →

Brooks newton wrote:

> 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?

No.

> 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).
>

I'm not really convinced by that line of thinking, part of testing WCAG2 is
things like "All functionality of the content is operable through a
keyboard interface", and "Information, structure, and relationships
conveyed through presentation can be programmatically determined or are
available in text."

Combine those criteria with the concept in WCAG2 of accessibility
supported: "Technology features can only be relied upon to conform to WCAG
2.0 success criteria if they are used in a way that is 'accessibility
supported'." I.e. works in common user-agents.

That means testing in common user agents, and if it doesn't work, it does
*not* "pass WCAG compliance muster."

> Do any accessibility experts out there ever tell their clients that some
> design patterns are inherently inaccessible, given the current state of
> technology?

Yes, most commonly because an enthusiastic developer has tried to apply
ARIA in a way that isn't supported (yet), and there needs to be a practical
solution in the meantime. Usually that situation could have been avoided if
(realistic) accessibility were considered earlier, and there is often a
simpler solution than the one they were attempting.

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?

Because that is a shed-load of work that would be out of date before it was
completed.

The matrix that would involve is mind-boggling. Browser testing is browsers
multiplied by OSs, you have to multiply perhaps 5 OSs by 4 or 5 browsers.
In practice, with certain OSes not having many browsers, you can usually
test in less than 10 combinations to cover most of the usage. Add ATs and
you are multiplying 5 * 5 * 5 ish? Taking off non-existant combinations
you'd still probably be looking at over 30 combinations? (I'm open to
corrections on that!)

Then multiply by the number of combinations of ARIA design patterns within
different contexts, and it would probably take longer than a month if all
the accessibility agencies dropped their paid work to tackle it together...
not practical.

Steve Faulkner (& I assume others at TPG) put together:
http://html5accessibility.com/ which is browser support for HTML5 tags.
That's a lot of work to do and keep updated (thank you Steve!). Then
multiply that by ATs and design patterns...

In practice I think most already have a good idea of what works in general,
and can test specific examples quite efficiently. In our work that is
usually what's needed, and we can't publish those examples because they are
not ours to publish.

There was a move to try something like this a couple of CSUNs ago, and I
won't speak for others, but for me it turned into quite a daunting,
repetitive and dull exercise; there was always something more interesting
to do.

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?

Overall I think the accessibility community is pretty good at sharing
information, just look at what people publish (compared to other
industries, or other areas of web development).

For ARIA these come to mind:
http://whatsock.com/tsg/ (probably the closest thing to what you are asking
for)
https://www.w3.org/TR/html-aria/
http://heydonworks.com/practical_aria_examples/

The "theoretical models" aspect is covered by the W3C in documents like:
https://www.w3.org/TR/wai-aria-practices/#aria_ex

It is just that the context of the implementation often affects its
practicality...

-Alastair

From: Steve Faulkner
Date: Thu, Feb 11 2016 5:00AM
Subject: Re: Recommending Widget Markup that Doesn't Work in Reality
← Previous message | Next message →

On 11 February 2016 at 09:51, Alastair Campbell < = EMAIL ADDRESS REMOVED = > wrote:

> For ARIA these come to mind:

and there is also - Notes on Using ARIA in HTML
http://w3c.github.io/aria-in-html/

--

Regards

SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;

From: Alastair Campbell
Date: Thu, Feb 11 2016 7:10AM
Subject: Re: Recommending Widget Markup that Doesn't Work in Reality
← Previous message | Next message →

Ah, thanks. I googled "HTML ARIA" and picked the wrong one!

From: Patrick H. Lauke
Date: Thu, Feb 11 2016 7:30AM
Subject: Re: Recommending Widget Markup that Doesn't Work in Reality
← Previous message | Next message →

On 11/02/2016 12:00, Steve Faulkner wrote:
> On 11 February 2016 at 09:51, Alastair Campbell < = EMAIL ADDRESS REMOVED = > wrote:
>
>> For ARIA these come to mind:
>
>
> and there is also - Notes on Using ARIA in HTML
> http://w3c.github.io/aria-in-html/

And it gets *real* fun once you see how any sufficiently complex ARIA
patterns (which were devised with a quite clear keyboard/desktop centric
view) fall apart for touch devices
http://w3c.github.io/aria-in-html/#aria-touch - with the advice I've
given to many clients recently to simply NOT implement certain patterns
as per ARIA and instead fall back to much simpler approaches. Most
recent example: combobox (autocomplete/type-ahead search type text field
with suggested values, which can be navigated using arrow keys on
keyboard) simply isn't workable for touch/AT users (I believe this was
mentioned on this list not so long ago).

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: _mallory
Date: Thu, Feb 11 2016 9:05AM
Subject: Re: Recommending Widget Markup that Doesn't Work in Reality
← Previous message | Next message →

THIS.
Happens to me and others all the time.

On Thu, Feb 11, 2016 at 02:10:32PM +0000, Alastair Campbell wrote:
> Ah, thanks. I googled "HTML ARIA" and picked the wrong one!

From: Brooks newton
Date: Thu, Feb 11 2016 1:08PM
Subject: Re: Recommending Widget Markup that Doesn't Work in Reality
← Previous message | Next message →

Many thanks to the honest responses to the questions I posed in post regarding implementing ahead of the curve accessibility solutions. I have had the privilege of working with some of the best minds in this business, some of who responded to my inquiry in this forum. Thanks for your feedback and for pointing me in the right direction to learn more. If only software manufacturers were held to the standards we are asking our developers to code to, we might have a faster path moving from theoretical accessibility to business as usual digital accessibility. And many kudos to those who have the imagination to conceive of theoretical solutions at the W3C. We have to able to imagine change before we can actually go about the nuts and bolts work to make it happen.

Sent from my iPad

> On Feb 11, 2016, at 8:30 AM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
>
>> On 11/02/2016 12:00, Steve Faulkner wrote:
>>> On 11 February 2016 at 09:51, Alastair Campbell < = EMAIL ADDRESS REMOVED = > wrote:
>>>
>>> For ARIA these come to mind:
>>
>>
>> and there is also - Notes on Using ARIA in HTML
>> http://w3c.github.io/aria-in-html/
>
> And it gets *real* fun once you see how any sufficiently complex ARIA patterns (which were devised with a quite clear keyboard/desktop centric view) fall apart for touch devices http://w3c.github.io/aria-in-html/#aria-touch - with the advice I've given to many clients recently to simply NOT implement certain patterns as per ARIA and instead fall back to much simpler approaches. Most recent example: combobox (autocomplete/type-ahead search type text field with suggested values, which can be navigated using arrow keys on keyboard) simply isn't workable for touch/AT users (I believe this was mentioned on this list not so long ago).
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>

From: Matt King
Date: Fri, Feb 12 2016 10:24AM
Subject: Re: Recommending Widget Markup that Doesn't Work in Reality
← Previous message | Next message →

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.

From: Brooks newton
Date: Fri, Feb 12 2016 5:02PM
Subject: Re: Recommending Widget Markup that Doesn't Work in Reality
← Previous message | No next message

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 ADDRESS 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.
>
>