I will not go into politics here, please bear with me if you are not a fan of the social media platform that is currently visited by 1/3 of whole world population (!).
I will just reflect on some key points Facebook engineers are exposing in their latest blog post on their accessibility efforts (opens in new window) and what does it mean for us that create our own web stories.
When you reset your stack you have the best opportunity to integrate accessibility
Every site or app will get to a point that needs a big decision – to rewrite or to replace. And they decided to rebuild. That was an ideal situation for incorporating accessibility and it is probably quite a popular developer’s dream anyway. Correct, improve, modernize. And great that they thought of accessibility!
Some dirty, but very sweet technical details on Facebook rebuilding their stack (opens in new window) – I will have to return to this article multiple times!
Accessibility from day 0 – linting with eslint-plugin-jsx-a11y and static type checking with Flow
Every crafts-person needs good tools and developers need them even more, so it was a natural choice for them to use linting tool eslint-plugin-jsx-a11y (opens in new window) and also checking static type with Flow (opens in new window).
Responsiveness of text in a developer friendly way
We know that we must use dynamic font size units to be accessible and to let our users control the font-size as they prefer, but it can be a bit difficult to match the designer’s blue prints for a developer in hurry.
So they came up with an interesting idea – let developers write font-sizes in pixels, just like they get from designers, but let the tools convert the them from fixed to dynamic – relative text sizes depending on the default root font size (REM).
So if they decide to change font size they can do it from single place. And users setting their font sizes in their browsers can be sure that all texts are being resized.
It is not always easy to have page headings in correct order when using dynamic renderings
We have probably been there – setting heading levels manually and then we must insert a new level and fix sibling levels and so on.
They made a simple concept for dynamic heading hierarchy, so that instead of defining heading levels manually they are just replaced with same component that then automatically define it’s own level according to it’s position.
Smart solution that makes sure heading levels are always in order.
Centralizing keyboard shortcuts and commands means full control
Doing it partially or globally can soon mean that same key is being used twice, for different actions, so on a long run it means difficult setup, debug and user experience too.
Centralizing them and also using context they are placed in is a much better strategy. Single API to the rescue, again.
Developer and automatic check tools are not enough, manual checks and tests are crucial
As we know – only relying on linting, type checks, syntax validation and automatic tools is very beneficial but not enough. Manual checks and tests, especially when considering whole pages or applications is a must.
And Facebook engineers have also proved this fact by introducing an graphical analysis tool that exposes markup validation errors and even introduce implicit visual barriers to testers, so that they can not miss eventual errors.
They say that – unlike popular open source extensions and plugins – they run this tool automatically, in the background, not even needing activation. They are just there – poking testers if something is wrong.
Style guide, re-usable elements that have built-in accessibility are key to continuous accessibility
Not unexpected – the authors of React are harvesting key advantages of their importable and extendable components with embedded and tested, built-in accessibility.
And of course when creating new components – their go-to reference is ARIA Practices Guide (opens in new window) as well. That brings accessibility consistence to the table and again, with reusing accessible components – we assure better overall accessibility.
Consistently managing focus throughout entire Facebook is challenging to say at least
You have probably done some DOM based focus setting code, or maybe even used some ref’s and similar attributes to manage focus via JavaScript so then it is surely clear that in such a complex solution as Facebook it is really not easy to make it work well.
They are solving it with custom React components that can be integrated and wrapping any actionable element they need. It must include quite a lot of combinations to take care of all best practice guidelines from ARIA if we think of all possibilities.
Screen-reader live regions solution
Again smart to centralize and while using React – why not use a React hook to make it append an aria-live region (opens in new window). And good point when removing duplicate announcements before adding clutter to the screen reader.
Their plans for the future
While I am not a fan of current alternative text solutions that are being generated by machine learning algorithms, they surely want to improve the image accessibility with usage of computer vision and some machine learning using deep convolutional neural network (opens in new window). I will not make any speculations, but I think that their learning data set is probably big enough for the ambition.
I hope they will succeed and make me change my mind.
We must all learn from this, it will do good to our accessibility efforts
I think their blog post is an excellent summary of everything we should all be doing. You may say that their budget, competencies and also public exposure are the reason, but I will suggest to look into technical practicalities that they share with us and try to embed at least some of them in our workflow – for the benefit of web accessibility.
