Accessibility Reporting for HE: The Human Touch

University web teams across the country have been preoccupied with this deadline ever since it was announced. As an agency that builds websites for HE, SMILE have been involved in these conversations from the off, preferring to pre-emptively build our websites to meet these regulations ahead of time.

However, universities whose current website pre-dates the announcement are understandably more anxious to seek guidance. Contributing to this anxiety is the fact that those who are in line to feel the sting are the institution’s policymakers, not necessarily their web team. The idea that your website might be unusable in a way that affects a substantial amount of its visitors, often in ways that are technically incomprehensible to anyone but web developers, is enough to strike terror into the hearts of University administrators. Not to mention the coming promise that those who run inaccessible websites might soon be punished by government agencies!

The Project

The first step towards making a website WCAG 2.0 compliant is to understand how and why it is not so. We have recently been working with Nottingham Trent University to help shine a light on exactly these questions.

We’re not going to delve into the results here. The output of our report exists as a blog itself. What we want to describe is the process and presentation of the results. Given the anxieties described above, we were keen to help produce a report that explained, in human terms, what the potential problems were, where they occurred in context and how they might be resolved.

The Method

We put the website through its paces utilising two strategies

• User Testing
• Automated Evaluation

It was important to us to gather qualitative evidence regarding the accessibility of the website from real users with real assistive devices and demonstrating a range of different levels of ability.

Alongside this, we ran the site through automated testing tool Sitemorse. Sitemorse analyses the codebase behind the site in order to flag any issues which contravene accessibility regulations. This can be incredibly useful as it will often bring issues to light that might otherwise go unnoticed – especially by users who do not use assistive devices to browse the internet. Such common issue include:

• Incorrect ordering of HTML headers
• Not providing descriptive labels for a range of items including buttons/fields
• Using the same id attribute for two separate labels

The Presentation

As with many of our recent analysis-based projects, we decided to present our findings as a blog. The results of this kind of projects can often appear quite dry, even impenetrable, to the average user. We were determined to provide a report that would work on two levels:

1. To help any future developers to isolate and resolve accessibility issues by presenting issue reference identifiers and code snippets.
2. To help non-technical staff to understand the meaning behind some of the opaque reference codes and descriptions by providing examples in context.

As you can see from the screen recording above, we first provide the reference code for the error along with its name in the title of the post. Beneath this we include the verbatim description of the issue taken from https://www.w3.org/ 

We then provide a ‘Practical Example’, which demonstrates the issue in context on the customer’s site itself. In this case, this takes the form of a screen recording though it could equally be an annotated screenshot or snippet of code. After a brief description of the issue in context, we provide a table which outlines all instances of the issue across the customer’s website.

The Conclusion

While WCAG 2.0 aims to make the web accessible for all, we believe that accessibility reporting should be equally accessible for all. The personnel on our clients’ teams all have different specialisms but a common goal. It is important that everybody understands the need for accessibility compliance. But going one step further to clarify the details behind the issues themselves, we hope to make the invisible visible and remove the unnecessary frustration often encountered by non-technical team members.