6 Accessibility Fixes for University and College Websites

computer screen showing HTML settings for accessibility

Maintaining Accessibility Requires Continuous Effort

If you read this brief article all the way to the end you will know the most frequently occurring accessibility issues we identified on Ontario’s university and college websites so you can fix them.

Our last article showed that keeping higher education websites accessible isn’t easy. We used an automated accessibility testing application on the home pages of Ontario’s university and college websites. The application assessed the types and number of issues found and we discussed a few caveats that need to be applied to the results of automated accessibility testing.

We found that six "errors" accounted for 80% of all the error types we measured on the 46 Ontario college and university websites. The errors correspond to measured divergence from the WCAG 2.0 rules and guidelines. While WCAG 2.0 compliance can be assessed programmatically, testing comes with a degree of false positives or negatives. And our preferred testing tool (Tenon.io) explicitly acknowledges this by assigning a confidence level to its results.

This week we examine each ‘potential’ error to explain why it is a concern and the benefit of resolving it. To maintain consistency with the previous article we’ve reproduced the relevant rows from the original results table.

The specific code examples used below come from the college and university website pages tested and reported in the last article.

1. This Link Text is Uninformative

Description of Uninformative Link Text
Occurrence Best Practice Description Message Text WACG Cross-Reference

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)

The number one error we found involves uninformative link text. These are hyperlinks displayed on a page for which the text is either not self-explanatory or ambiguous for visitors using assistive devices.

A typical example is the common practice of placing "Learn More" text on buttons. Almost all site visitors would benefit from clearer wording such as "Register for Fall Open House" or an equivalent.

Image illustrating ambiguous link text

While the text "error" can be fixed through content editing, automated accessibility testing tools will likely identify two potential errors in the underlying HTML code. The first being the uninformative "Learn More" text, the second results from the potential confusion/frustration caused by placing identical links adjacent to each other. In this case the "Join us …" text and the button take a visitor to the same new page – but for a screen reader user, this is unnecessary extra navigation. And, a non-screen reader visitor is likely to use a well-worded button to continue navigating. The code snippet below illustrates the issue:

<p class="subtitle"><a href="/openhouse/" class="apply-now">Join us Saturday November 18 from 10am to 2pm.</a></p>
<p class="text"><a href="/openhouse/" class="check-btn">Learn more</a></p>

2. This Link uses an Invalid Hypertext Reference

Description of Invalid Hypertext Reference
Occurrence Best Practice Description Message Text WACG Cross-Reference

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

Automated testing found that a ‘technical’ issue about the use of hyperlink text was the second most frequently occurring error.

In this error, the underlying HTML code includes the following: <a href="#">To the same page</a>

We’d normally expect to see a URL between the quotation marks, which would allow a visitor to go to another page. In this case the link will return a user to the top of a page. It is valid HTML, but confusing if you are accessing the page with an assistive device.

The full code snippet in which this ‘error’ was found is as follows:

<a href="#" class="shiftnav-searchbar-toggle shiftnav-toggle-main-block shiftnav-toggle-main-ontop">
<i class="fa fa-search"></i><br /></a>

There are a few ways to avoid using the "#" as the anchor target:

  • completely omit the href="#" attribute
  • replace "#" with "javascript:void(0)"
  • if the anchor element does not have an id attribute, create one and then set the href value to # as in <a id="this_one" href="#this_one">A link to itself</a>

The selection of the appropriate replacement depends on the overall desired effect and whatever other page content relates to the anchor element in question (such as javascript code)

3. This ‘id’ is Being used More Than Once

Description of 'id' Not Being Unique on a Web Page
Occurrence Best Practice Description Message Text WACG Cross-Reference

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

In HTML, the id attribute is used to specify a unique element within a web page, to add navigation or even JavaScript processing. The key is that the id is unique to avoid ambiguity, particularly for visitors using assistive devices to interact with web pages. Again, automated testing can only go so far: there may be sound reasons for a particular construction, but testing can highlight instances that should be subject to review.

This third most commonly detected error is primarily an issue for developers. However, in maintaining accessible content, it is an issue that content editors should understand and be able to discuss with developers to ensure that content is not being made less accessible.

Here’s a specific example found during our original testing, where the id="skip-link" is detected twice in the same code snippet:

<li id="skip-link" class="last leaf active menu-mlid-456">
<a href="/" id="skip-link" class="active">Back to top</a>
</li>

4. Image missing ALT attribute

Description of Missing ALT Attribute
Occurrence Best Practice Description Message Text WACG Cross-Reference

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

The images used on web pages can be tagged (strictly speaking, have text added to the alt attribute) to ensure that visitors that cannot see the images can have the description text read to them. Assistive devices (and search engines) can readily parse a web page’s HTML to read text associated with an image and allow a visitor to understand what the image conveys.

However, unless unambiguous, informative descriptive text is added during content editing, visitors using assistive devices and search engines cannot interpret web page images. This leads to ambiguity and confusion and content not meeting its intended purpose.

Here’s a typical example, in which the alt attribute in the image element is empty. The context and relevance of the associated image is difficult to interpret for visitors using assistive devices and effectively invisible to search engines:

<img src="http://humber.ca/assets/images/home/home2017/fall.jpg" alt="" width="800" height="800">

5. This Form Element Has No Label

Description of Form Element Missing a Label
Occurrence Best Practice Description Message Text WACG Cross-Reference

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

Website visitors using assistive devices need assistance to understand the appropriate data to supply for on-page elements such as search boxes or forms. Assistance and context are provided by ensuring that input areas have associated, relevant descriptive text or labels. The visible ‘placeholder text’ is not necessarily interpreted by assistive devices.

Given that almost all university and college websites locate a search box at the top right of the home page, it is a simple fix to ensure that the search is useable by all-comers.

<label for="q">Search the site for anything:</label>
<input name="q" id="q" class="form-control" placeholder="Enter Search Here..." type="text">

6. Same alt Text on Images with Different src Attributes

Description of Repetitive use of ALT Attribute Text
Occurrence Best Practice Description Message Text WACG Cross-Reference

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

As noted in 4 above, tagging images used on web pages aids visitors using assistive devices by providing relevant description text.

However, if the same descriptive text is associated with different files (the src attribute, in the heading above), then meaning and context are potentially ambiguous. In practice, automated testing tools will likely treat repeated empty alt attributes as an example of this issue.

Here’s an example of this error found in adjacent images during our original testing. It is also a reasonable supposition that the description "thumb" doesn’t accurately inform a visitor about the nature of the image:

<img src="/documents/10315/38840/banniere-semaine_metier_2017_1122x460_03.jpg/57b313c0-f7a0-480d-16be-809474f8c892?t=1509624786951" alt="thumb">

and

<img src="/documents/10315/38840/fr_1122x475_lacite_etudiant_un_jour.jpg/cbdcce32-cb93-4d96-94d4-27006a4e548a?t=1506086516688" alt="thumb">

If you have made it this far and want to understand more about the most frequently occurring types of accessibility issues read the following post on the Tenon.io website: How long does it take to test 25 Billion web pages? (the link will take you to the most relevant section of the post).

 

Sign Up for Email Delivery:

We collect the following solely to email you new blog posts.

* indicates required
 

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

 

 

Don’t have accurate and current information on all the websites you own? Not able to monitor and check each website’s content quality and risk status? Let’s talk about how we can help.

 

Blog photo image: unsplash.com