Accessibility is a process
A website is never really ‘finished’. We talk about websites ‘going live’, and they really do take on a life of their own and need looking after. Content will be added and changed (more on this later), new functionality may appear over time, and at some point, the marketing department will ask for a design refresh!
This means that accessibility is a process, not a one-off checkbox exercise. One of our largest clients, HS2 appoints the Digital Accessibility Centre (DAC) to regularly test the accessibility of their website and report on any issues they may find, and how best to tackle them.
While we perform a certain amount of in-house accessibility testing at Studio 24, one of the great things about working with an organisation such as DAC is that the testing is carried out by people who use assistive technologies such as screen readers on a day-to-day basis.
Building complex interactions is hard
One of the most complex aspects of the HS2 website is mapping the route. There are currently two interactive maps on the website, one showing the planned route and how it connects to the wider rail network, the other showing additional details such as the location of the tunnel boring machines and the individual work items forming part of the entire construction project.
We use Leaflet, an open-source JavaScript library, in conjunction with ESRI mapping to plot the data and link from the map to more detailed information. Text versions of both maps are provided as a fail-safe.
The greater the level of interactivity required, the more knowledge developers need about how to use JavaScript and, potentially, WAI-ARIA (Accessible Rich Internet Applications) to meet accessibility requirements, and the more effort has to be put into accessibility testing.
Sometimes that testing will reveal things that we can fix directly, but sometimes the onus will be on the providers of the third-party software to resolve underlying issues. In such cases, we need to feed that detail back to the software provider, as they may be unaware of the problems.
While almost anything can be made accessible, using native and semantic HTML elements and interactions wherever possible, and following WAI-ARIA authoring practices when that isn’t possible, makes for far less effort in the long run.
Accessibility requires collaboration
When first building a site, and when adding any new features, our focus is on creating an accessible framework for presenting content to users. This requires collaboration.
It’s possible for an otherwise accessible website to provide inaccessible content, which is why at Studio 24 we view accessibility as an ongoing collaborative effort with our clients.
One of the main purposes of the HS2 website is to keep people informed about the progress of the project, and a team of content editors is tasked with adding and updating website content. It’s vital that they know how to make that content accessible.
The reporting from the Digital Accessibility Centre covers all aspects of the website. Where there are issues with the content this is flagged and feedback is made available to the content editors for remediation.
Finally, from the client’s perspective, it’s important that any new team members responsible for editing content are given guidance on how to make sure that content is accessible, as part of their onboarding process.