Yesterday I attended the Inclusive Design and Accessibility meetup (“idea11y”) at De Voorhoede in Amsterdam, which was about development tools, graphic design and, the surprise act, the accessibility of React apps.
Florian Beijers, who currently interns at Microsoft, talked about his experience using text editors. He showed us popular editors like Sublime Text and Atom, and how they are impossible to use for him as a blind user. Some just read out BLANK BLANK BLANK, due to bugs in the underlying framework (Electron, in Atom’s case). It was easy for us all to conclude that the products had not looked into accessibility much. During the talk and Q&A two questions arised: why does this happen, and how hard is it to make products accessible? The why, Florian said, seems to be a combination of lack of knowledge and lack of education, which then also causes accessibility bugs to be deprioritised. If you don’t know that your designs or your code places a burden on some of your users, why make improvements? Then the how. According to Florian, adhering to standards can help a great deal in making things accessible. An example is labeling: if you do not use the standard way of labeling controls in your application, your user’s accessibility tools will not understand them.
Design consultant Agnieszka Czajkowska talked about accessibility from a design point of view. She emphasised that good design can help a great deal in removing barriers for some of your users. To come to good design, she said, it is important to include users early on, do accessibility by default and avoid treating it as an optional feature. This is something I personally see a lot in projects: specific user stories or backlog items for accessibility (‘as a user, I want all the things to be accessible’). It doesn’t work like that, every task should include doing it accessibly. In the Q&A, the discussion moved towards flexibility of interfaces. Some people need more contrast or larger fonts. If an interface is flexible enough, they can use their browser settings to do this. Agnieszka said this comes down to giving users agency: make sure your interface allows for rather than hinders user preferences. In her talk, she showed a practical example of this: on a site she used, text overlapped with other text when she set a larger font size. With responsive design, it is perfectly possible to avoid this.
De Voorhoede’s Jasper Moelker stepped in at the last minute to do a lightning talk that he had done before for the ReactNL conference. In the talk, he used examples from the React docs and showed how they performed in three browsers: Chrome (a modern browser), Opera mini (a proxy browser) and Lynx (a text browser). Sadly, most of the examples worked great in Chrome, hardly in Opera mini and not at all in Lynx. He then showed how to rewrite the examples by using semantic HTML. Basic markup 101 like pairing labels with inputs and wrapping form controls in form elements helped a great deal and made some of the examples work in all three browsers. Takeaway: semantic markup is extremely important. It is a great strategy to ensure your application is understood by the largest amount of browsers/devices possible. Again, as Florian also concluded, following existing standards helps a great deal. Another strategy Jasper recommended is to choose ‘mount nodes’ wisely: some turn their whole body into one big React app, which does nothing without React. Instead, you could turn specific parts of your page into mini React apps, and have the rest of the page contain sensible defaults. The latter likely deals more gracefully with failures.
This was my first idea11y meetup, and I have had a great evening. Many thanks to the organisers for putting this event up and De Voorhoede for their hospitality. I am looking forward to attending again!
Comments, likes & shares
No webmentions about this post yet! (Or I've broken my implementation)