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:26AM

Emmanuel Pelletier wrote:
> [...]
> React comes with a lot of tooling, and with all this tooling comes
> help in various ways, including a11y. For example, the most known tool
> to begin with React is create-react-app. This tool has
> eslint-plugin-jsx-a11y
Yeah - or you can test with AT, use WAVE etc or A N Other a11y tool.
> All in all, I think the accessibility of dynamic web content is not
> great, more because of lack of knowledge and training than because of
> the current frameworks. I guess people are now directly learning JS
> frameworks and skip learning HTML semantics?
Thats interesting and I hope is not the case But you are probably right
that youngers devs are likely 'learning the framework' and not case for
semantics until it is pointed out why they are necessary but still - the
React framework itself isn't a blocker for a11y IMO.

Thanks

Josh
>
>
> Emmanuel
>
>
> On 10/19/18 1:55 PM, 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