WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: State of Accessibility in Dynamic Web Content

for

From: JP Jamous
Date: Oct 19, 2018 11:15AM


Almost all of you have provided great feedback on this topic. I just wanted
to share my 2 cents based on my experience with various teams that use all
of those JS frameworks.

1. There is definitely a web design shift taking place here. It is not new.
In fact, it has been occurring slowly but surely and now it has gotten more
attention, as more and more sites started adopting it.
2. Money and time are the driving factor behind those JS frameworks, because
developers can code quickly and push their code out to those various CMS
systems.
3. Let's not just point the finger at others, rather look at what we have
been doing as individuals with disabilities. We are not being reactive
enough. How old is WCAG 2.0? Now after 10 years we realize that we need a
2.1 version? All that time responsive UIs have been out and we were not
paying attention to that. I would really like us to stop and evaluate our
progress versus the progress of companies.
4. While proper HTML semantic is highly important, in my opinion, RAD -
Rapid Application Development has changed that tremendously. If we review
VB.NET, ASP.NET and many other languages, we realize that companies like
Microsoft are providing developers fully customizable components right out
of the box. Drag, drop and code around it. That's how it was and now it is
even worse, Drag, Drop, and Bind together. The IDE writes all the code in
the background. So for the old and new developers, this is time saving and
they love that because they can get the work done in a much shorter time
span.
5. Since time and money are the driven factors behind all projects, who has
the time to learn ARIA? Many developers that I deal with on daily bases tell
me, "ARIA is so hard to comprehend." If I stop and think outside the box I
can relate to what they were saying. ARIA does not work alone and with the
interoperability of JS, HTML, CSS and ARIA coding becomes a nasty process
that is time consuming and time is money.


I am not making excuses or pointing fingers. I am just looking at the market
from a neutral prospective.

If demand is greater than supply, then we would have a shortage of supply.
If products are expensive, consumers will look for alternatives or
substitutes. Those are very basic economic concepts. Unless we think
economically as accessibility experts, we will remain behind the current
languages that are out on the market and causing us to deal with this large
inaccessible JS framework revolution.

As an advocate for people with disabilities, I know first-hand how hard it
is to get laws passed and for change to occur. I also understand that making
the rest of society realize the need to accessibility is hard. I do want to
take a look at assistive technology manufacturers for a moment because they
are a part of this equation too just like browsers are.

Why aren't VFO and NVDA standardizing things? I understand one is for profit
and the other is open source. However, if they truly care, they should
collaborate efforts and work to standardize how screen readers parse HTML
content. VFO will not lose money and go out of business. They just provided
a new feature with JAWS 2019 where it is like Office 365. Pay a $90 a year
and use any version of JAWS. Isn't that better than the $1,000 that they
were imposing on their consumers? Plus, it is consistent steam of income
coming in for them just like Microsoft realized that a service based program
is much better than a one-time fee.

By standardizing things, it would make it much easier for us to push back on
inaccessible markup. I have to always remind developers that we use JAWS/IE,
NVDA/FF and Voiceover/Safari because we cannot test with all the various
combinations. It is time consuming and time is money. We are always back to
this basic fact even as accessibility experts.

While I have diverted a bit from the technical part, it was necessary
because we have to address the economical part first. That is the driving
factor that we keep forgetting. I was in that loop back in 2016, but as of
2017, I started realizing why we are unable to have the accessibility
traction we need. If time is money and that is how the private sector
operates, we cannot focus on our own rules to play the same game.
Accessibility is highly important. Yeah that is a quite important rule, but
that is not the rule that the rest of the world is playing by. So we are
indirectly setting ourselves for failure that way.

Besides the WebAIM survey, I have yet to find strong surveys and usability
studies that can give me solid numbers to take and face business owners with
to help them recognize the importance of accessibility. Most people who are
using assistive technologies or have disabilities do not want to provide
that information. I totally understand their right to privacy, but if that
information can provide the numbers we need then we can have stronger cases
to face both the private and public sector with and achieve our goal.

I just wanted to shed the light on a few things that we are not considering.
We can e-mail back and forth all day until we drop, but nothing will change
if we cannot focus as a unified group on the realistic points that are
causing us to be in the situation we are in now. Until we start addressing
those points in a unified way, we will remain to operate the same way we
have been and accessibility will always remains way behind cutting-edge
technologies.

One last remark. Notice that I used the word "Unified" multiple times. I did
that on purpose because we are individuals with different opinions and we do
disagree about different things. That is fine if we disagree as a group
amongst ourselves. However, we cannot disagree when we are facing the world.
We have to be unified to achieve our goals and objectives.

This is just my 2 cents folks. I do not expect a reply from anyone and you
do not have to agree or disagree with me. I just wanted to voice my opinion
based on my observation with large corporates. If we can start the change at
those large corporates, we can make that replicate down to medium and small
businesses.



--------------------
JP Jamous
Senior Digital Accessibility Engineer
E-Mail Me |Join My LinkedIn Network
--------------------


-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
Joshue O Connor - InterAccess
Sent: Friday, October 19, 2018 8:26 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] State of Accessibility in Dynamic Web Content

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-201
8/
>>>
>>>>>
>>>>>
>>>>> 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-accessibil
ity-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