WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: _mallory
Date: Feb 10, 2016 2:31PM

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