Keeping Higher Education Websites Accessible is Hard to Do

programmers working to make a site accessible


Websites need constant attention to ensure they meet performance, user experience and accessibility standards and to follow leading practice. Maintenance is an essential, but dull, task readily eclipsed by implementing new features, content or capabilities.

Our research reveals how difficult it is to keep any website attribute in peak condition, even when that attribute is a ‘must do’ rather than a ‘should do’. Experience shows that some website attributes are regarded as ‘should dos’, for example, have unique page titles or page description text. But, in some jurisdictions, there are ‘must dos’. One of these is to meet accessibility standards.

This article uses website accessibility as a special example of the principle that, just as aircraft require scheduled maintenance to remain operational, websites require continuous attention to meet their objectives and, in some cases, their obligations.

This is not an article about the quality of higher education website accessibility implementation. Although, the results should prompt further testing and thinking about ongoing maintenance.

We submitted the home pages of the 45 websites of Ontario’s publicly funded universities and colleges through’s automated accessibility testing tool to understand the range of issues that accumulate on web pages. We selected this group, as legislation in the Province of Ontario makes website accessibility a ‘must do’, and thus likely to receive closer attention than ‘should do’ tasks.

Our research results show that automated testing revealed improvement opportunities on all the test sites. It also highlighted commonly occurring issues readily remediated through content editing process improvements and programmed maintenance.  We can infer that ‘should do’ website attributes probably receive even less attention, while having the same capacity to reduce a site’s effectiveness for its visitors.

Website Accessibility Philosophy

In establishing a regulatory regime there is a fundamental dichotomy: to be rules- or principles-based.  The latter sets policy objectives, measures compliance, but leaves how to comply open ended. The former creates rule books and assesses compliance by testing against the rules.

Website accessibility is rules-based, so, theoretically, web pages can be parsed programmatically to evaluate their compliance.  In practice, accessibility experts caution against pure automation, as it misses the subtleties of making websites accessible to different audiences.

Nevertheless, automated tests perform two very useful functions.  They readily and quickly highlight basic opportunities to improve web page structure and design, across an entire site. They can also help categorise issues as being best resolved by attention to content, code or CMS configuration: allowing root causes to be identified and corrected.

How Did the Websites Fare?

The test group

Since 2005, Ontario’s public institutions have been subject to the Accessibility for Ontarians with Disabilities Act (AODA). Under this legislation, Ontario’s colleges and universities have a clear a timetable by which their websites need to meet accessibility standards.

As of January 2014, new higher education websites needed to meet Web Content Accessibility Guidelines (WCAG) 2.0 level A.  By January 2021, the standard will rise to WCAG 2.0 level AA.  In talking to individuals responsible for websites in the sample group, level AA is seen as a minimum acceptable standard for current sites.

The current situation is that accessibility is part of long-term strategic planning, implementation is well underway, but execution quality still hangs on the same, regular verification and maintenance processes as all other website elements.

The test process – what did we find?

To keep the data analysis manageable, we tested each institution’s main home page: the 45 pages generated a total of 1,270 data points in response to the tests.  We focused on home pages, presuming these to be the gateway to the overall website and thus duly ‘optimised’ for accessibility.

We absolutely acknowledge that some home pages exist primarily to route traffic and have simple structures, while others serve wider purposes and are more complex and may less readily comply with accessibility “rules”.

Consequently, our analysis focuses on ‘error’ type frequency rather than error rates, to accommodate the fact that different home pages had different objectives.

Our testing found 25 different error types. We categorised the errors using what calls “best practices”, each of which cross references to a WCAG 2.0 guideline.  

The single most frequently occurring error was, “failing to label links with informative text”. In fact, 80% of all the errors found relate to lack of link, image, title or button labels. And, these are issues remedied by improved content editing processes rather than coding or CMS reconfiguration.

The following chart summarises the category and relative frequency of the 25 error types we found:

Relative frequency of error types found runs 74 different page tests, assigning a confidence level to whether it has detected an issue or not.  On average the web pages in our sample group passed 68 of the 74 tests.

The web pages were hosted on the following set of content management systems (CMS): Adobe Experience Manager, Agility CMS, Cascade Server, Drupal, Episerver, IronPoint, Liferay, SharePoint, Sitecore, Umbraco and WordPress. We found no correlation between the error types and the CMS in use.


Providing appropriate levels of website accessibility is becoming increasingly important for higher education institutions. Designing and building websites with high levels of accessibility takes considerable knowledge, skill and judgment.

In common with all complex systems, websites drift off mandate without constant attention.  As the results of these (and other tests we’ve documented) show, accessibility and other key website performance attributes cannot be sustained unless a process for verification and maintenance is in place and followed.


Here’s a list of the institutions we tested along with links to their information about institutional accessibility, which covers more than just website accessibility.


Institution Accessibility Information Link

Algoma University

Algonquin College

Brock University

Cambrian College

Canadore College

Carleton University

Centennial College

Collège Boréal

Conestoga College

Confederation College

Durham College

Fanshawe College

Fleming College

George Brown College

Georgian College

Humber College

La Cité

Lakehead University

Lambton College

Laurentian University

Loyalist College

McMaster University

Michener Institute

Mohawk College

Niagara College

Nipissing University

Northern College

OCAD University

Queen's University

Ryerson University

Sault College

Seneca College

Sheridan College

St. Clair College

St. Lawrence College

Trent University

Université de Hearst

University of Guelph

University of Ontario Institute of Technology

University of Ottawa

University of Toronto

University of Waterloo

University of Windsor

Western University

Wilfrid Laurier University

York University


Here’s a list of the error types identified, in order of relative frequency of occurrence, along with the links to the underlying WCAG 2.0 guideline.


ID Occurrence Best Practice Description Message Text WACG Cross-Reference



This link text is uninformative.

Do not use generic text in links. Use text in the link that accurately and concisely conveys where the link goes.

WCAG 2.0, Level A: 2.4.4 Link Purpose (In Context), WCAG 2.0, Level AAA: 2.4.9 Link Purpose (Link Only)



This link uses an invalid hypertext reference.

This link's href attribute is not properly constructed.

WCAG 2.0, Level A: 4.1.2 Name, Role, Value



This id is being used more than once.

This id attribute value is being used more than once. If this id is being used to reference a UI control, that can cause issues for users with assistive technologies.

WCAG 2.0, Level A: 4.1.1 Parsing



Provide clear and informative titles for all frames and iframes

Frames (only iframes are valid in HTML5) need a title attribute that describes the frame's content or purpose. Add a title attribute to the frame element for that. Even if the frame does not have content that is relevant to users, the frame's title should say that. If you do not, assistive technologies will simply announce the frame's URL to users.

WCAG 2.0, Level A: 2.4.1 Bypass Blocks



This form element has no label.

Give all controls a label. This allows all users to understand the type of information expected in the field.

WCAG 2.0, Level A: 1.1.1 Non-text Content, WCAG 2.0, Level A: 1.3.1 Info and Relationships, WCAG 2.0, Level A: 3.3.2 Labels or Instructions, WCAG 2.0, Level A: 4.1.2 Name, Role, Value



Image missing alt attribute

All images need an alt attribute. If you do not supply an alt attribute, that'll mean that users who ca not see the image will not understand what the image conveys. Make sure that the alt attribute value is a useful, concise, and clear description of the image.

WCAG 2.0, Level A: 1.1.1 Non-text Content



Same ALT text on images with different src attributes

This image has the same alt attribute value as another image but the images have different file names. This probably means that these images are different and that they should each have their own distinct alt attribute values.

WCAG 2.0, Level A: 1.1.1 Non-text Content



This element has a role attribute even though native semantics are available.

Replace this element's role attribute with native semantics.

WCAG 2.0, Level A: 4.1.2 Name, Role, Value



This may be an implicit heading.

This text appears to be styled to look like a heading. If this text is meant to be a heading, use heading markup. Doing so will add semantic value to this text, which will let users understand the content's structure.

WCAG 2.0, Level A: 1.3.1 Info and Relationships, WCAG 2.0, Level AAA: 2.4.10 Section Headings, WCAG 2.0, Level A: 4.1.2 Name, Role, Value



This button is empty.

This button has no text within it. People who use assistive technologies like voice-dictation software will not be able to refer to the button by name, and users of screen readers will not have any information about this button's purpose.

WCAG 2.0, Level AA: 2.4.6 Headings and Labels



This markup uses a tabindex value that's greater than 0.

Applying tabindex values greater than 0 very often causes issues with the tab order of the page. Explicit dictating the tab order like this often forces users into an interaction pattern that diverges from what they're expecting. Instead of applying a specific tabindex, make sure that the source order of interactive controls matches their intended interaction order.

WCAG 2.0, Level A: 2.4.3 Focus Order



This table does not have any headers.

This table does not contain any th elements. If this table is used for layout, replace it with a proper layout controlled with CSS. If that's not possible, add role="presentation" to the table.

WCAG 2.0, Level A: 1.3.1 Info and Relationships



Event handler bound to non-actionable element that lacks role

This element is typically not able to react to events however it has events bound to it. In such cases, the element should have the appropriate ARIA role applied to it. Doing so will allow users of assistive technologies to know what to expect and how to interact with this control.

WCAG 2.0, Level A: 2.1.1 Keyboard, WCAG 2.0, Level A: 4.1.2 Name, Role, Value



This heading element is blank.

This heading element has no text within it. Headings are an important wayfinding and page-level navigation mechanism for screen-reader users, and each heading should provide clear and informative text.

WCAG 2.0, Level A: 1.3.1 Info and Relationships



These list items have no parent element.

These list items do not have a proper list container. Place these inside a list container, such as ol or ul so assistive technology users can more easily understand them. That will also allow the assistive technologies to properly convey the structure of the list.

WCAG 2.0, Level A: 1.3.1 Info and Relationships



This element has an accesskey attribute.

Do not use the accesskey attribute

WCAG 2.0, Level A: 2.1.1 Keyboard, WCAG 2.0, Level A: 2.1.2 No Keyboard Trap



This option list may need optgroup elements.

Because this select element includes so many options, you may need to organize it into optgroups. This is not a hard requirement. If the options in this select lend themselves to being categorized, consider placing each group into its own optgroup

WCAG 2.0, Level A: 1.3.1 Info and Relationships



These tables are nested.

Tables should not contain sub-tables. Tables are intended to organize sets of data according to their structure. which is conveyed to users of assistive technologies. When you nest tables within other tables, those relationships can become difficult or impossible to discern. If you need to keep the nested table structure, add role="presentation" to the table

that you are using for layout.

WCAG 2.0, Level A: 1.3.1 Info and Relationships, WCAG 2.0, Level A: 1.3.2 Meaningful Sequence



The language of this page is not set.

The language of the document has not been set. Set the document's language by adding the lang attribute to the element using a ISO 639-1 language code.

WCAG 2.0, Level A: 3.1.1 Language of Page



This image button has no alt attribute

Like all other images, image buttons require alt attributes. The alt attribute should clearly and concisely convey what happens when the button is activated.

WCAG 2.0, Level A: 1.1.1 Non-text Content



This text is preformatted.

Avoid using the pre element unless pre-formatting makes sense, such as in the case of code examples. If this pre element is being used for purely visual presentation purposes, it should be replaced with proper structural markup styled with CSS

WCAG 2.0, Level A: 1.3.1 Info and Relationships



ONMOUSEOVER handlers should have an equivalent ONFOCUS handler

This element has an ONMOUSEOVER event handler, but no ONFOCUS. Depending on the type of interaction, this element should react to ONFOCUS the same way as it does with ONMOUSEOVER

WCAG 2.0, Level A: 2.1.1 Keyboard, WCAG 2.0, Level AAA: 2.1.3 Keyboard (No Exception)



This link points to an image.

This link goes directly to an image. So it is not possible to supply a text alternative to the image. A better way would be to open the image in a lightbox or on another page along with a useful text alternative for the image.

WCAG 2.0, Level A: 1.1.1 Non-text Content



This field label is not unique.

These field labels have identical text. Make sure that fields have unique labels. If you have a legitimate reason to reuse the label text, make sure that the different fields are grouped appropriately using a fieldset

WCAG 2.0, Level AA: 2.4.6 Headings and Labels



Give each page a clear and informative title element.

This page has no title. The page title is the first thing announced by assistive technologies, so it is an important wayfinding cue. Provide a page title that's clear, informative, unique, and concise.

WCAG 2.0, Level A: 2.4.2 Page Titled


Sign Up for Email Delivery:

We collect the following solely to email you new research.

* indicates required

MailChimp stores your details. We do not share data with third parties.

Blog photo image: