At IF, we believe that our work is better when it is open. An important part of producing open work is ensuring what we do is accessible to everyone, including in digital spaces. Websites that aren’t built and tested with the needs of all internet users in mind can result in frustrating experiences for people who access the web in different ways.
To this end, we have recently introduced some changes to our Data Permissions Catalogue, to make it more accessible and ensure it’s up to the same standard as our main website. Our starting point was the Web Content Accessibility Guidelines (WCAG), compiled by the World Wide Web Consortium’s Web Accessibility Initiative (WAI). These are a set of guidelines for building accessible websites. Following them helps ensure sites are “perceivable, operable, understandable and robust”.
Guidelines in this category are concerned with ensuring content on a web page can be perceived by users in various ways. For example, if someone can’t see page content, they can still access the content in another way (e.g. by listening to a screen reader). To meet this, we added alt-text to the images on the catalogue, making sure that it was descriptive and useful in the context of the page. We also added captioning for the video on our ‘About’ page using WebVTT formatting.
We used ARIA attributes to add extra semantic meaning to the site. The ARIA, or “Accessible Rich Internet Applications”, suite of attributes was developed by the WAI to add extra information to HTML documents when needed. For example, we used ARIA attributes to indicate to people who use screen readers when our pattern category menu was open and closed, and how to engage with it.
This category contains guidelines that address the operability of the web page using different input methods. First, we implemented some basic changes to improve keyboard navigability, including adding custom visible focus states for links and skip-to-content buttons. We also tested that people accessing our page with a keyboard would not encounter any strange jumps between content or fall into any ‘keyboard traps’.
A challenge was implementing keyboard control of the embedded video on the ‘About’ page. As the video was inserted into the page via iframe element, it was not possible to change the tab index or focus states for the playback controls. To get around this, we set up some event listeners, to listen for a user’s keyboard inputs and connect them to playback controls via the Vimeo API. Now, when someone uses the keyboard to navigate to the video, they can start and stop the video with the spacebar or enter key. When they navigate away from the video, it pauses automatically.
The guidelines in this category ensures page content and layout is understandable and readable. Among other things, making content more readable involves avoiding jargon and excessively technical terms. At IF, we aim to write in Plain English across all our pages. In this way, building accessible sites is something that all members take part in, not just developers or designers.
Finally, sites must be robust. This means making the site compatible with the variety of software that people use to navigate the internet, especially assistive technologies. These guidelines involve writing well-formed and conventional markup that would not “break…or circumvent” assistive technologies.
It has been an interesting and useful exercise to apply these accessibility improvements to the Data Permissions Catalogue. If you’re interested in testing them out, you can turn on keyboard navigation or a screen reader (here’s how to enable accessibility tools on your Mac, Windows, Android or iPhone device) and head over to the catalogue. Finally, we understand that building accessible sites is an ongoing project, and we are always looking for ways to improve and open our sites to more people. Any feedback you have is very welcome. Drop us a line at email@example.com with any suggestions.