WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: State of Accessibility in Dynamic Web Content

for

From: Emmanuel Pelletier
Date: Oct 19, 2018 3:36AM

Hi,

Sorry, kinda late to the party but this is questioning me.


I agree there is definitely a problem with accessibility in the
JavaScript development world. For some reason, lots of developers just
don't know about accessibility, or only know a tiny glimpse of it. From
my point of view (of a JS dev) though, I see big companies talking more
and more about accessibility in their frameworks and browsers, stuff you
would not see even two years ago. It's not perfect, because as you
showed, even devs in the biggest companies and leading the big framework
are not that familiar with a11y, but I think it will get better on this
point.


But I don't quite understand what is the problem with React, JSX, Vue,
Angular or any framework in particular. All of those sure let you create
custom widgets, but they are all rendered in HTML in the end. The custom
widgets are all composed of standard HTML elements.
All the a11y issues are the fault of the authoring of the component, not
the framework itself.
Do you see a difference of usability in a jQuery component implementing
a specific ARIA design pattern, and a React component implementing the
same one?


I agree ARIA can be hard to use correctly to implement components the
best way. But I find the ARIA design patterns a huge help to create
common components. You say ARIA is often wrongly used. Do you also think
that when a specific design pattern is followed? I personally assume
that if I follow a pattern to the letter, the outcome will be the best.
So, while I test in a screen reader if restitution is OK, I don't go
further by asking myself if what I did is screenreader-user friendly:
the pattern tells me it is.


The real issue I see that is often not dealt with, is with full-JS
websites or "single page apps". Most of them break navigation for screen
readers. You can have each of your React UI component accessible by
itself, if you don't do something about the navigation between pages in
a full-JS website, screen reader users are easily lost.



Emmanuel Pelletier
Web developer, Empreinte Digitale

On 10/10/18 12:28 PM, Brandon Keith Biggs wrote:
> 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/>;
> > > > > .
>