WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: State of Accessibility in Dynamic Web Content

for

From: Joshue O Connor - InterAccess
Date: Oct 19, 2018 7:19AM

Hi Brandon,

> I have honestly never had a problem with navigating between pages with
> something like React Router.[..]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.
Right, so with some background knowledge of a11y I think you can get
quite far with React.

I think devs will mostly struggle getting to grips with 'out of the box'
React dev, and without some a priory a11y knowledge may quickly be at
see. But I don't think it inherently stops the creation of pretty
accessible content (in as much as it also may not promote its creation).

My 2 cents, thanks.

Josh


Brandon Keith Biggs wrote:
> 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
>> >> >> >> >>
> > > > --
Joshue O Connor
Director | InterAccess.ie