Explorify’s approach to building accessible web content

Web accessibility can be tricky to demonstrate. Many features added to help make websites accessible are not visible to the naked eye and if you don’t rely on them or dig into the code, it’s not always obvious when they are missing. The Explorify team has recently released its new Science Leader Toolkit. This has been a massive piece of work for the whole team and we’re really proud of what we’ve collectively achieved. The aim of this article is to shed light on the team’s approach to accessibility and some the unseen accessibility features that we have been working on to make the Science Leader Toolkit accessible.

As a team we are driven to make Explorify accessible to all the teachers and primary school students who use the website. If asked to construct a manifesto for the team’s approach to accessibility it would go as follows:

1. We openly question each other on how components are designed and built during workshops, planning, demos and code reviews.
2. We recognise that accessibility takes time to design, implement and test. Designers and developers are given the time and resources needed to explore and build accessible systems.
3. Accessibility is not a ‘nice to have’, when estimating how long a piece of work might take to complete, you must factor in the time it will take to make it accessible.
4. We recognise that different features require different levels of attention, we have a range of different techniques for testing accessibility and pick the right one depending on the feature.
5. We monitor how the site is performing and will respond decisively when it becomes clear that teachers are struggling to use or understand part of the system we built.
6. We build components which conform to the Web Content Accessibility Guidelines (WCAG) AA standard.

Building the toolkit

When we first received the content for the Science Leader Toolkit we knew that it was going to be tricky to design and build, there is a lot of content and it would be a challenge to present the information without overloading the teachers, which can be an accessibility concern itself. Our approach to minimize this issue was to place most of the content inside of expandable sections which the teacher can open and close as and when they like:

True to the first point from our accessibility manifesto, when we presented our preliminary designs to the wider digital team the expandable sections were highlighted as a feature that will require a lot of attention to be made accessible. I’m going to walk through three of the accessibility concerns and the technical solutions we used to overcome them.

1. Focus styling on buttons

Here we can see that as we use the tab key to cycle through the expandable sections, the titles receive a dark outline around their outer edge to indicate which element is currently focused:

There are many reasons why a user might be navigating your webpage with a tab key. WCAG provides this list of users who are known to often rely on keyboard navigation in their Keyboard: Understanding SC 2.1.1 section:

• People who are blind (who cannot use devices such as mice that require eye-hand coordination)
• People with low vision (who may have trouble finding or tracking a pointer indicator on screen)
• Some people with hand tremors find using a mouse very difficult and therefore usually use a keyboard

In most cases this is one of the easier features to build. Browsers provide a focus outline on many elements by default. Often these outlines don’t fit with the aesthetic of the site and designers and developers remove them and as a result many websites don’t have focus states on buttons! You can easily test this by pressing the tab key on any website, can you clearly see which element is currently in focus? It’s a very quick way to know if an organisation values accessibility or not. You can read more about the importance of focus visibility in the WCAG guidelines.

2. Hiding non visible content to all users

Building upon the last point, we know that certain elements such as buttons and links should show a visual indicator when they receive focus. A problem we had with these expandable sections was that when tabbing through the page, the links inside the expandable sections were receiving focus when the section was not expanded and the links were not visible. This means that teachers using the site could lose track of which element is focused and could become confused. This is what it looks like, notice how the focus outline disappears and then appears again when tabbing through the section titles:

This was easily fixed by making sure the content within an expandable section has the display: none CSS property when the section was not expanded, which means that the content is visually hidden, hidden from screen readers and removed from the list of tabbable elements when not expanded.

The complexity comes when combining this with the animated opening and closing of the expandable sections. Applying the display: none property has an immediate effect and it would hide the content without any transition. The solution was to write some JavaScript which waits until the sections have animated closed and then applies the display: none property. This is simple enough but can be time consuming to implement and test. It would have been much simpler to not bother going to these lengths for a feature which the majority of users wouldn’t notice was missing. It’s great that Explorify lives by the rules of our accessibility manifesto and we had the time and support to make sure Accessibility is not just a ‘nice to have’.

3. Adding aria-expanded and aria-owns

For sighted users it is clear when an expanded section has been opened and the content is visible and when it is not. For non-sighted users who rely on screen readers and other assistive technologies we have to programmatically declare these changes so they be communicated using non-visual methods:

• Purpose: This button controls an expandable section and can display hidden content.
• State: The button’s expandable section is currently open or closed.
• Location: Where the button’s expandable section can be found.

The first two states are controlled by adding the aria-expanded=“[true/false]” attribute to the buttons like this:

<button aria-expanded=”false”>
  Subject audit: focus areas and key questions
</button>

When this section is opened and closed this value should be changed to let the assistive technology know there has been a change of state so it can alert users to this change, we use JavaScript for this.

One way to test that this is working as expected is to use a screen reader when developing the code. As a mac user I have the Mac VoiceOver screen reader available at my disposal. When the button receives focus it reads out loud ‘Action plan, collapsed, button’ (Mac also displays the text it is reading out loud in a grey box on screen):

Again, this is simple enough to implement however there is hidden complexity which must be considered. In the same way that different browsers sometimes display websites differently, screen readers can also differ in the way that they implement the rules of the web. The fact that VoiceOver recognises the aria-expanded attribute and reads out ‘collapsed’ does not necessarily mean that other technologies such as the JAWS screen reader will do the same. This is where you have to ask further questions:

• How well supported is this feature?
• How will other assistive technologies interpret this code?
• How big is the risk if this doesn’t work correctly?
• Could we build this in a way that doesn’t require this piece of technology?

Ultimately there will be times when you can’t answer these questions and need to test the site with real teachers of different abilities to see how it is performing, if you don’t have the skills in house you can employ companies such as Zimmo Accessibility or Ability Net to test your website as Explorify has done in the past.

I hope this has given an insight into some of the techniques that we have used to make our website accessible, and demonstrates the Explorify team’s dedication to this goal. Please get in touch or leave a comment if you have any questions and I will do my best to get back to you.