Keeping Higher Education Websites Accessible is Hard to Do

programmers working to make a site accessible

Summary

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 Tenon.io’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 Tenon.io 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

 

Tenon.io 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.

Conclusions

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.

Appendix

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

https://www.algomau.ca/about/administration/human-resources/accessibility/

Algonquin College

http://www.algonquincollege.com/policies/policy/ac03-aoda-integrated-accessibility-standards-regulation/

Brock University

https://brocku.ca/accessibility/

Cambrian College

http://cambriancollege.ca/accessibility/

Canadore College

https://www.canadorecollege.ca/about/accessibility

Carleton University

https://carleton.ca/accessibility/

Centennial College

http://www.centennialcollege.ca/accessibility-at-centennial/

Collège Boréal

http://www.collegeboreal.ca/a-propos-de-boreal/accessibilite/

Conestoga College

http://www.conestogac.on.ca/accessibility-at-conestoga/

Confederation College

http://www.confederationcollege.ca/accessibility-at-confederation

Durham College

https://durhamcollege.ca/about/accessibility

Fanshawe College

https://www.fanshawec.ca/about-fanshawe/corporate-information/accessibility-fanshawe-college

Fleming College

https://flemingcollege.ca/about-fleming/accessibility

George Brown College

https://www.georgebrown.ca/accessibility/

Georgian College

http://www.georgiancollege.ca/about-georgian/corporate-information/accessibility/

Humber College

http://hrs.humber.ca/support/support-resources/humanrightsresources/aoda.html

La Cité

http://www.collegelacite.ca/accessibilite.htm

Lakehead University

https://www.lakeheadu.ca/about/accessibility

Lambton College

https://www.lambtoncollege.ca/Accessibility/

Laurentian University

https://laurentian.ca/accessibility

Loyalist College

http://www.loyalistcollege.com/about-loyalist/accessibility-and-aoda/

McMaster University

https://accessibility.mcmaster.ca/

Michener Institute

http://michener.ca/discover-michener/accessibility-at-michener/

Mohawk College

https://www.mohawkcollege.ca/about-mohawk/accessibility

Niagara College

http://www.niagaracollege.ca/aoda/

Nipissing University

http://www.nipissingu.ca/information/Pages/Accessibility.aspx

Northern College

http://www.northernc.on.ca/accessibility/

OCAD University

https://www.ocadu.ca/about/accessibility.htm

Queen's University

http://www.queensu.ca/accessibility/

Ryerson University

http://www.ryerson.ca/accessibility/

Sault College

http://www.saultcollege.ca/Accessibility.asp

Seneca College

http://www.senecacollege.ca/about/aoda-plan/

Sheridan College

https://www.sheridancollege.ca/about/accessibility.aspx

St. Clair College

http://www.stclaircollege.ca/studentservices/accessibilityservices.html

St. Lawrence College

http://www.stlawrencecollege.ca/about/college-administration/accessibility/

Trent University

http://www.trentu.ca/ohrea/accessibility/

Université de Hearst

http://www.uhearst.ca/accessibilite

University of Guelph

https://www.uoguelph.ca/accessibility/

University of Ontario Institute of Technology

http://studentlife.uoit.ca/student-accessibility-services/index.php

University of Ottawa

http://www.uottawa.ca/respect/accessibility-hub/

University of Toronto

https://www.utoronto.ca/accessibility

University of Waterloo

https://uwaterloo.ca/human-resources/accessibility

University of Windsor

http://www.uwindsor.ca/ohrea/53/accessibility

Western University

http://accessibility.uwo.ca/

Wilfrid Laurier University

https://www.wlu.ca/about/accessibility/index.html

York University

http://accessibilityhub.info.yorku.ca/

 

Here’s a list of the error types Tenon.io 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

106

16.0%

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)

113

14.8%

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

179

9.4%

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

53

7.4%

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

49

7.4%

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

1

7.4%

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

61

7.4%

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

178

5.3%

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

142

4.1%

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

41

3.7%

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

25

2.5%

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

131

2.0%

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

114

2.0%

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

28

2.0%

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

144

1.6%

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

177

1.2%

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

50

1.2%

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

125

0.8%

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

118

0.8%

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

45

0.8%

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

136

0.4%

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

69

0.4%

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)

57

0.4%

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

39

0.4%

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

26

0.4%

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: unsplash.com