Accessibility is very important to the AD&S team. We have taken several approaches to identifying and improving accessibility issues with our applications. I will discuss some methods and tools we have used with respect to the recently deployed web site.
Drupal 8 Accessibility
Drupal 8 has made massive accessibility improvements over previous versions. The most readily apparent to our editors is the default requirement of alternative text. If you’ve created content on the site and uploaded an image you’re aware of this.
Default Drupal 8 image uploader with required alternative text.
If you upload an image you are required add alternative text in order to save the content. This in and of itself is a great addition. However, merely adding alt text doesn’t improve accessibility unless the alt text is descriptive enough and useful for the users. This is a good article on alt text and tips on how to write them.
Proper Semantic Markup
We strive to write proper semantic markup so that the headings are structured in the proper order. What does this mean exactly? Well, take a look at the Thompson Library page. If you were to look at the page source you would see that the title of the page, ‘Thompson Library’ is an H1 heading. This is the top level heading. Then there are some paragraphs of text underneath that. Further down on the page you’ll see ‘Events’ and ‘Exhibits’. These are essentially sections of the page but since they are below ‘Thompson Library’ in terms of hierarchy, they are H2s. Finally, the titles of the Events and Exhibits are coded as H3s. Screen readers pick out these headers and provide outlines of the content to users. Ensuring that we are using proper headings helps users navigate through the page.
In addition to our coding standards, I’ve also applied constraints to the WYSIWYG editor in Drupal so that editors can add only H2s and below to their content. This ensures that there are not multiple H1s on the page.
Screen-Reader Only Text
We use icons on the web site quite a bit. In some cases we display icons without text next to them. How will visually-impaired users know what we mean by these icons? In these cases we use screen-reader only text.
Example of icons without explanatory text.
Markup of screen-reader only text
What we are doing in this case is coding a span which says that this link will lead to something that will ‘reserve a study room.’ By applying the class of ‘sr-only’ this is hidden from the display but will be read by screen readers.
Tabbed Navigation
The ‘mega menu’ navigation that we have on the top of each page is navigable by tabs. This is very important for screen readers. Of course most users navigate through this mega menu using a mouse. However, it is possible to navigate through this menu via the keyboard and tabbing to different sections.
Tools
We use two primary tools to determine accessibility issues. One tool is the WAVE (Web Accessibility Evaluation Tool) plugin for the Chrome browser. On any web page you can activate this plugin and get feedback on problems and also elements that are well-structured.
In addition to this tool we also utilize Google’s Lighthouse tool to run audits on a representative sample of all of the pages on the web site. By representative I mean a sample of basic pages, location pages, collection pages, news items, event and exhibit pages and others. This is a similar tool to the WAVE tool but provides a more comprehensive check and explanation of the results.
Screenshot of results of an accessibility scan using Lighthouse.
In Conclusion
Accessibility is an element of web development that is never finished. Like the rest of our design and development workflows, we approach accessibility iteratively: providing new features, testing accessibility and making improvements where necessary.
