E-mail List Archives
State of Accessibility in Dynamic Web Content
From: Brandon Keith Biggs
Date: Oct 10, 2018 4:28AM
- Next message: JP Jamous: "Re: Testing with JAWS/NVDA on a virtual Windows 8/10 machine (Parallel's) running on a MAC"
- Previous message:
: "Inclusive Design 24 (#id24) is only hours away" - Next message in Thread: Emmanuel Pelletier: "Re: State of Accessibility in Dynamic Web Content"
- Previous message in Thread: None
- View all messages in this Thread
Hello,
With React and JSX widgets being adopted by so many companies, there needs
to be a concerted effort to make the new interfaces accessible to screen
readers.
(By JSX syntax, I mean <CustomElementName
prop1="bla"<Children</CustomElementName>)
Currently there are no user-friendly React frameworks for screen reader
users, not even the ones that say they are "accessible". The only framework
that comes close is the AccDC port to React that is still in Beta:
https://github.com/WhatSock/bootstrap-react
Why is this a problem?
Over the last 3 years I have seen a progressive shift in sites using React
and they are reimplementing the same functionality across sites and it is
not accessible to screen reader users or keyboard users. If the trend keeps
moving in this direction (and this JSX syntax is common across all the most
downloaded frameworks):
https://javascriptreport.com/javascript-frameworks-by-the-numbers-winter-2018/
We are going to quickly see a web full of inaccessible sites, similar to
what happened before HTML sites were easily accessible by screen reader
users.
As a screen reader user web developer and systems acquisition manager, I'm
extremely scared that the web will become as inaccessible as Unity in a few
years.
What's happening?
React, Vue, and I believe Angular, all encourage the use of creating custom
widgets. This means adding HTML markup is seen as being cumbersome and not
needed by those who don't know about accessibility. Comments on HTML
include: "It's not worth the time learning the HTML syntax", "HTML widgets
are too hard to customize", and "HTML markup takes too much time".
This leads to many companies creating their "own" widgets (which
functionally are identical to what is already out there).
For larger companies and projects who are conscious of accessibility,
developers need an extensive knowledge of Aria to make sure everything is
working. Unfortunately, the component developer has no time to study Aria,
and for them, it's seen as a pretty useless job (similar to a blind
developer adding CSS into their sites). On top of that, Aria is so complex,
it's extremely easy to get wrong. Regardless, I can't think of one
accessible site from the above frameworks that does not use Aria. From the
Using Aria W3C Working Draft:
"If you can use a native HTML element or attribute with the semantics and
behavior you require already built in, instead of re-purposing an element
and adding an ARIA role, state or property to make it accessible, then do
so."
https://www.w3.org/TR/using-aria/
The problem is there are no HTML elements for accordions, menus, grids,
tabs, or the other dynamic elements. There are a few dynamic elements, such
as datalist and video, but despite this, Aria is being used more and more
to reimplement this functionality. The problem is it is not being used
correctly, even in widgets like autocomplete that already have an HTML
counterpart. Just going down a list of frameworks, The following widgets
use aria, but have a bad user experience:
https://material-ui.com/demos/menus/
https://material-ui.com/demos/autocomplete/
https://ant.design/components/menu/
https://ant.design/components/checkbox/
https://react-bootstrap.github.io/components/dropdowns/
https://react-bootstrap.github.io/components/forms/
Then other frameworks just choose not to use Aria, even for the most simple
of things:
https://react.semantic-ui.com/elements/input/#states-loading
https://react.semantic-ui.com/modules/accordion/#types-standard
As shown from the WordPress example:
https://rianrietveld.com/2018/10/09/i-have-resigned-the-wordpress-accessibility-team/
Accessibility is not something that is easy for react developers to
implement, just because Aria is so difficult and sighted developers try and
give screen reader users the same experience as the sighted users, even if
this is not user-friendly or even possible. (Thinking of always having
menus expanded).
When new users come into Aria, they are expecting something similar to a
React component that has all the accessibility functionality built in, so
all you need to do is put the tags in and everything is plug-and-play. As
one starts to learn Aria, they find that instead of being super simple and
easy to use, it is extremely low-level and there is so much that goes into
a good design, it's too much work to do properly.
Tutorials for these frameworks, where developers learn best-practices,
sometimes don't create accessible interfaces:
https://reactjs.org/tutorial/tutorial.html
This means hundreds of thousands of developers are learning that the above
interface is OK. "Facebook is doing it, so it must be correct". But try and
think of a good way of doing the above using HTML or Aria without getting
super complex. If you think of a way, here is the Github issue:
https://github.com/reactjs/reactjs.org/issues/78
What should we do?
There are lots of options for what should be done, but whatever happens, it
needs to happen as close to the source as possible to have the widest
effect. As you see, each level higher up from 1 in the system requires
exponentially more resources:
1. The very bottom is HTML. Aria has defined very clear component
types for tabs, accordions, menus, dataGrids, and all the major dynamic
interfaces. HTML should be updated with elements utilizing these dynamic
types. Each of the elements should be hard to not make accessible (similar
to h1). It should be as easy to create a Grid as it is to create a table.
HTML widgets should also be made extremely easy to customize visually,
following the two-pronged functional and visual design paradigm. Aria
either needs to be made much higher-level, or be unnecessary except for
extremely complex projects, similar to how people don't actually write
MathML or Web Assembly unless they really need too.
2. If not HTML, then the frameworks themselves need to have
"official" UI components that have been tested by screen reader users and
that work very well. The endorsement and usage in tutorials of these
official UI frameworks will mean most developers will heavily consider
using them in their projects. W3C and or other orgs like Web AIM will
probably need to be monitoring these frameworks to make sure they are
creating widgets that are user-friendly.
3. A task force needs to go around to all the major UI libraries for
each framework and give pull requests to the different components that need
help.
4. The accessibility community needs to rally around one of the most
popular and adopted frameworks, such as Material UI, make sure it is
perfect with Aria, and they need to push it in all their companies. The UI
framework should work in different frameworks and be advertised on any
accessibility related tutorial site.
5. Frameworks such as AccDC need to be developed and the
accessibility community needs to rally behind adoption of these accessible
frameworks. Large companies need to adopt these frameworks and they need to
appear in the "top 10 frameworks" pages. These frameworks need to work with
many different view frameworks, such as React, Vue, and Angular, and be
accessible in each one. The framework/s need to bee advertised on every
tutorial, WCAG, and site related to web accessibility.
6. There needs to be laws enacted in each country, similar to the
ADA, but related to the web. As part of this law-making, taskforces need to
be created to do one of the above options.
(This order comes from Leverage Points: Places to Intervene in a System by
Donella Meadows:
http://donellameadows.org/archives/leverage-points-places-to-intervene-in-a-system/
)
I would like to hear from those who have worked on HTML and Aria, what is
holding back the creation of dynamic HTML elements?
From other developers, what are your thoughts on the options higher up? Are
there popular frameworks that would be easy to get adopted at a larger
company? What makes a company wish to create their own widget library? What
is keeping frameworks such as AccDC from being touted as the most
accessible framework?
Thank you,
Brandon Keith Biggs <http://brandonkeithbiggs.com/>
- Next message: JP Jamous: "Re: Testing with JAWS/NVDA on a virtual Windows 8/10 machine (Parallel's) running on a MAC"
- Previous message:
: "Inclusive Design 24 (#id24) is only hours away" - Next message in Thread: Emmanuel Pelletier: "Re: State of Accessibility in Dynamic Web Content"
- Previous message in Thread: None
- View all messages in this Thread