E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 8 (In chronological order)

From: Brandon Keith Biggs
Date: Wed, Oct 10 2018 4:28AM
Subject: State of Accessibility in Dynamic Web Content
No previous message | Next message →

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/>;

From: Emmanuel Pelletier
Date: Fri, Oct 19 2018 3:36AM
Subject: Re: State of Accessibility in Dynamic Web Content
← Previous message | Next message →

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/>;
> > > > > .
>

From: Joshue O Connor - InterAccess
Date: Fri, Oct 19 2018 4:11AM
Subject: Re: State of Accessibility in Dynamic Web Content
← Previous message | Next message →

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

From: Brandon Keith Biggs
Date: Fri, Oct 19 2018 5:55AM
Subject: Re: State of Accessibility in Dynamic Web Content
← Previous message | Next message →

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 ADDRESS 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
> > > > >

From: Emmanuel Pelletier
Date: Fri, Oct 19 2018 7:13AM
Subject: Re: State of Accessibility in Dynamic Web Content
← Previous message | Next message →

I don't quite get how React encourages the use of non-semantic HTML and
jQuery encourages the use of semantic HTML. I'd even say the contrary.

Both tools allow you to do basically the same thing, which is, whatever
you want with the DOM. And, just like in the React community, most of
the jQuery plugins out there are not accessible.

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 included, which looks for common a11y errors in
your code and lets you know about it.

And yeah like you said, it's not hard to resolve the navigation problem
in SPAs. It's just that it's a mostly unknown practice. And most router
library authors do not talk/care/know? about it. But React definitely
does not prevent you to deal with this issue.

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?


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 ADDRESS 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
>> >> >> >> >>
> > > > > .
>

From: Joshue O Connor - InterAccess
Date: Fri, Oct 19 2018 7:19AM
Subject: Re: State of Accessibility in Dynamic Web Content
← Previous message | Next message →

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 ADDRESS 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

From: Joshue O Connor - InterAccess
Date: Fri, Oct 19 2018 7:26AM
Subject: Re: State of Accessibility in Dynamic Web Content
← Previous message | Next message →

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 ADDRESS 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

From: JP Jamous
Date: Fri, Oct 19 2018 11:15AM
Subject: Re: State of Accessibility in Dynamic Web Content
← Previous message | No next message

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
--------------------