WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: State of Accessibility in Dynamic Web Content

for

From: Brandon Keith Biggs
Date: Oct 19, 2018 5:55AM

Hello,

React is a tool that is extremely powerful and extremely easy to make
inaccessible content with.

There is a very prevalent culture of only using divs and spans in react (Do
a search on twitter for "divs and spans react" and you will see people
talking about only using divs and spans).

This means developers who don't know any better are forgoing semantic HTML
for some reason and if they are not willing to research why semantic HTML
is useful, then they are not going to research how to implement Aria
correctly.



JQuery encourages the use of semantic HTML.



Design patterns are OK, but some of the Aria design patterns are extremely
difficult to follow and are not very forgiving if one thing is wrong.
Trusting design patterns, especially with Aria, has a very high chance of
making a bad user experience (See all the component frameworks who had a
bad implementation in my first post). The only design pattern I have seen
work consistently is creating semantic HTML pages which are being quickly
replaced with Aria, divs and spans.



Other developers will use a major component library trusting that it's
accessible, but it is most definitely not.



I love react, but it does not do enough to enforce component accessibility.
Instead, it encourages the use of Aria. It is also extremely difficult to
do accessibility related actions like moving focus or doing roving tabindex
in react. If you create an ARIA live region with react patterns without
using aria-atomic="true", then the screen reader will only read the few
letters that have changed in the region.



I have honestly never had a problem with navigating between pages with
something like React Router. Sure it's not perfect, but it is usable unlike
many of the components. I think to make something like React Router
completely accessible, it only takes a few lines of code to jump the screen
reader to the first heading when a new page loads or add an ARIA live
region to tell the screen reader the page has changed.



So it's not that one expects the framework to do everything, it's just the
fact React encourages the use of non-semantic HTML of spans and divs.

Thank you,


Brandon Keith Biggs <http://brandonkeithbiggs.com/>;


On Fri, Oct 19, 2018 at 3:12 AM Joshue O Connor - InterAccess <
<EMAIL REMOVED> > wrote:

> My 2 cents. When working with React you can focus (obviously) on the
> component level and add various ARIA name, role, value properties etc as
> needed and it quite effective. When managing state via Redux or
> whatever you can use JS to inject ARIA as you go and while JSX syntax is
> a mashup, it seems forgiving to me regarding ARIA use in any of the
> widgets etc that I've built.
>
> I think if you don't expect the framework to do all the work for you,
> the flexibility that React gives you - if you have a reasonable level of
> a11y knowledge, can be a plus.
>
> HTH
>
> Josh
>
> Emmanuel Pelletier wrote:
> > 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/>;
> >> > >> > >> > >> > >> .
> >>
> > > > > > > > >
>
> --
> Joshue O Connor
> Director | InterAccess.ie
> > > > >