Originally posted on marcus.io.
Usually, when talking about modern JavaScript frameworks and accessibility, the dominant opinion is "React and company are bad for for the inclusive web". But in my opinion, it is not the frameworks that are to blame – you can write accessible or inaccessible code, just like you would (or wouldn't) in plain, old, toolchain- and component-less HTML. Rather, what leads to inaccessible apps in the end is education and framework ecosystems: First, boot camps and trainings that focus on features, instead of HTML/CSS fundamentals. Secondly, inaccessible code in tutorials and the overall lack of awareness (admittedly, this is also valid for the web platform as a whole).
But this post is not about real or perceived problems of modern JavaScript frameworks – it's about using their strengths, their unique features or architectural approaches for the sake of accessibility. This week I asked on twitter about ideas of how to use frameworks for a good cause, so to speak: In what ways could React, Vue, Angular and Co and their features actually facilitate inclusive designs?
Let's turn the WebApp/React/A11y discussion around: Do you know of examples where framework characteristics, component based architectures, their abilities etc. actually help #a11y, or at least ease building thoughtful and inclusive applications?
There are advantages
I got great replies to that. Here's my try of summarizing, clustering and interpreting the answers:
Developer experience
Make accessible solutions part of the developer experience - that means: make things easy and fun to use. Use the architectural advantage that everything (including helpers or linters for accessibility norms) is just a npm install away.
Externals: usable, internals: accessible
With ideal components, all the accessibility features are taken care of, are battle-tested so to speak – but hidden away in their "engine room". The developer just uses the components interface, so to speak. Or as Hidde de Vries puts it: Separating the components' internals from its usage layer (more in his corresponding blog post "Baking accessibility into components")
Making accessibility hard to circumvent
Make the usage not only a joy but ensure that it's actually an effort to make an implementation inaccessible (David Brunelle's statement via Dan Abranov). He links Starbucks' React pattern library as an example.
Perry Trinier writes that the component-based architecture can help us enforcing accessibility features by setting up related required prop types (e.g. input labels, legend for a fieldset)
Use all of the framework's functionality...
Your framework has features that aim to make your life as a developer easier, for example concepts like mixins in Vue or hooks in React. Marcy Sutton, James Nimlos, and Almero Steyn suggest to use these for managing ARIA states and property values, e.g. for example generated unique IDs for ARIA references (aria-labelledby, aria-describedby, aria-controls et cetera), or explicit labels of your inputs (this concept: <label for="foo">Name:</label><input id="foo" /> – where "foo" would be the generated id).
...and its design approach
In his tweet, @giuseppegurgone mentioned that you could use a framework's declarative nature for you for accessibility features. Guiseppe also wrote a detailed blog post about what he means by this: "Building accessible modals with React".
Automate...
Almero Steyn reminds us: We can let our framework and the fact that we are not only writing markup, but actually are programming help us with your document outline: For example by automating your headline levels with the Heading component of tenon UI (idea by Sophie Albert)
...or use props in a smart way
If you don't want to go full automation, you can still use props to pass the appropriate heading level into you component, as Heydon Pickering wrote in last year's "Managing heading levels in design systems"
Both sides of the (app) story
@accessabilly likes that frameworks offer "the possibility to have (mostly) identical code on server and client at the same time. This offers opportunities for Progressive Enhancement."
Conclusion (for now)
Thanks again to all respondents! All in all these replies a very good starting points for deeper research and frankly speaking really inspiring stuff. And motivating – on the one hand, to dive in deeper into the framework's advanced concepts, but on the other hand, motivating to check all future features for suitability to improve accessibility. So that hopefully in the months and years to come this list of "framework-exclusive accessibility advantages" grows and grows!
Top comments (0)