As we have said before, the community of people who maintain websites at Carleton (that’s you!) is great at being supportive and proactive about accessibility. To maintain this momentum, we are offering to scan websites for accessibility, to check for any errors in our template or your content.
How we assess accessibility
There are two elements to the process. To start, we use a third-party application called PopeTech to scan a website. This involves counting the number of pages, posts, events, and any other types of post or page on the site and feeding the total into the application. It indexes every page and post on the site. We can then run the scan over all those indexed pages.
The other part of the process is browsing through the site to sample a portion of the content. (We look at between ten and twenty percent of all pages.) This is because not every component of web content can be assessed by a robot (which is what refer to the PopeTech application as). An example would be alt text on an image. PopeTech cannot tell if a piece of alt text is appropriate, or whether an image even needs alt text in the first place. Some things need a human.
What’s the outcome?
From the PopeTech scan we receive a report detailing any errors on the site. There are two ways in which to numerate the errors on a website:
- The number of errors on a website
- The number of instances of those errors on a website
It is an important distinction. It could spell the difference between have one error repeated 500 times on your website, and having 500 different errors dotted around the pages. One error repeated 500 times often means the problem is in the template, not in your content.
From our visual audit of the site we pull together a list of any less than optimally accessible content, areas for improvement, areas of excellence.
We’re in this together
There are two general areas in which accessibility errors can occur: the template and the content. Web Services controls the template; you control the content.
When we report back to you about accessibility errors we will be very clear about which errors are in the template, and which are part of the content that you control.
Examples
There is a lot to take in when it comes to accessibility. To help process everything we will provide you with a list of errors with details of why it is important to correct each issue, and suggestions on how to achieve this. Let’s take a look at a couple of examples:
Issue 1: Missing form label
Location: https://carleton.ca/your-site/your-page
Responsibility: Web Services
Your action: None
Issue 2: Table missing heading row (<th>)
Location: https://carleton.ca/your-site/your-page
Responsibility: Website owner
Significance: The header row <th> helps associate table cells with the correct row/column headers. A header row that contains no text may result in cells with missing or incorrect header information. This makes it harder to access and interpret the content of the table for users employing a screen reading application to browse this page.
Your action: Add a header row to your table in order to establish a label for each column in the table. Please contact Web Services via the ITS Service Desk if you require assistance with this.
Issue 3: Linked image being used as a link does not possess alt text.
Location: https://carleton.ca/your-site/your-page
Responsibility: Website owner
Significance: Unlike ordinary images, images being used as links must have a piece of alt text attributed to them. This text should describe what will happen/where the user will be taken if they click the image. E.g., Register for this event now
—
Hopefully this gives you some idea of what to expect if you request an accessibility scan from Web Services. We take accessibility very seriously. We don’t have all the answers but we will certainly do all we can help to make your websites as accessible as possible.