I find it notable when the blog of a major accessibility-focused company like Deque publishes an article called Debunking the Myth: Accessibility and React. Mark Steadman is essentially saying if a site has bad accessibility, it ain’t React… it’s you. The tools are there to achieve good accessibility.
React didn’t use a <div>
for a <button>
, you did. React didn’t force extra markup all over the page when you decided to not use a Fragment. React didn’t forget to change the title of the page because that was something you neglected.
Is it different how you have to do it in React versus how you have to do it in some other framework or CMS? Yes, it is. Different, but neither worse nor harder.
I’m optimistic that well-made React components focused on accessibility can have a positive impact on the web. Just today I was pair programming and looking at some HTML for a toggle UI in a Rails template. It had a little bug we wanted to fix, which required an HTML change. But this toggle wasn’t a component, it was a chunk of HTML used in dozens of places on the site. Gosh, did I wish this part of the site was architected with a proper components instead, so the change would have fixed all toggles on the site at once. All JavaScript frameworks encourage this kind of component building, which is just smart front-end architecture if you ask me.
Where did the bad wrap on React come from? Well, we could debate that for days. Is it that JavaScript-focused developers never got the HTML training they needed? Maybe. Was it gnarly, unsemantic React code that was written/shared in the early days that others copy and pasted too many times? Maybe. I’m not sure we’ll ever know. The important thing is that we all do a better job now.
I think it’s largely this
In many of the resources discussing accessibility, they show the standard, vanilla way to do it. So React developers can’t simply learn React and accessibility each in a vacuum. They have to learn React-flavored accessibility. Or maybe accessibility-flavored React. I’m not saying they shouldn’t learn the fundamentals of accessibility without React, they absolutely should. But it’s that React has different accessibility requirements that makes it feel like React isn’t as good with accessibility.
It’s not as simple as just applying semantic markup.
WAI Aria is not an acceptable sticking plaster for developers. It merely adds hints, however, some of those predicates are debated and not always adopted in all screen readers, accessibility plugins.
The test will always be, can you use your application in all the browsers, accessibility plugins and screen readers with only your keyboard. Whilst you navigate, are you informing the user of placement and action? Can the user proceed and reverse their actions? Are all your interactions available and accessible via the keyboard?
It may be that you can make an accessible Web application, however, you will have make some compromise and potentially force your user to use a specific set of browsers/plugins.
In order to force your user to do that your going to have to have a pretty compelling offering, otherwise they simply move on or worse, they’ll pursue legal action, if they’re feeling particularly put out by the lack of access.
It’s not as simple as just applying semantic markup.
WAI Aria is not an acceptable sticking plaster for developers. It merely adds hints, however, some of those predicates are debated and not always adopted in all screen readers, accessibility plugins.
The test will always be, can you use your application in all the browsers, accessibility plugins and screen readers with only your keyboard. Whilst you navigate, are you informing the user of placement and action? Can the user proceed and reverse their actions? Are all your interactions available and accessible via the keyboard?
It may be that you can make an accessible Web application, however, you will have make some compromise and potentially force your user to use a specific set of browsers/plugins.
In order to force your user to do that your going to have to have a pretty compelling offering, otherwise they simply move on or worse, they’ll pursue legal action, if they’re feeling particularly put out by the lack of access.
Using semantic HTML in React is actually no more difficult than authoring a “traditional” website… that is, if you know what you’re doing.
The problem is twofold IMHO.
JavaScript, back-end or fullstack devs who use React to build UIs may not have a solid foundation in more traditional front-end skills (HTML/CSS, etc). This leads to inaccessible apps.
React libraries, of which there are 1000s, are so easy to npm install, so there’s a good chance you’ll end up using inaccessible code somewhere in your app. And if you don’t know any better, it’ll end up in production code.
It’s up to us to educate, raise bugs on inaccessible React library code, etc.
Btw, accessibility is not just a developer responsibility. It’s the whole team… design/ux, QA, stakeholders.
Yeah , even I also agree with you , it’s not a single man responsibility to blame on the React
This has been an argument that irks me for some time.
JSX and React are just SCSS for HTML. If it is built with A11y in mind, it will be accessible. I think one if the biggest problems is that JS/React developers don’t concern themselves with accounting for the unknown in their components. A good react component should make intelligent defaults while embracing that it will be used in ways you don’t predict. Often this is as simple as passing on the props you don’t need.
https://codesandbox.io/s/flamboyant-sun-4rb2j?fontsize=14&hidenavigation=1&theme=dark