You are now in the main content area

Laurentian Web Accessibility

Web accessibility means providing all people the opportunity to participate in the online experience fully, regardless of ability. When sites are correctly designed, developed and edited, all users can have equal access to information and functionality without discrimination.

Under the Accessibility for Ontarians with Disabilities Act (AODA), the Government of Ontario requires all websites meet Level AA requirements as outlined by Web Content Accessibility Guidelines (WCAG) 2.1. These guidelines were developed to address barriers relating to visual, motor, auditory, and cognitive disabilities. Laurentian University is dedicated to removing barriers and creating equal access to information and content for people with disabilities in order to ensure an inclusive online experience.

Best Practices for Creating Accessible Websites

An accessibility check should not be the final step prior to the launch of a new website. When it is, many accessibility issues are often identified, leading to a costly redesign and a delayed launch. To avoid this, accessibility must be part of the development process from the beginning, not a check tacked-on at the end.

Whether you are building a new website or reviewing an existing one, Laurentian University’s Information Technology and Digital Strategies departments have identified key components within WCAG success criteria to consider, listed below.

A full list of WCAG Success Criteria is available by W3C. 

 

Writing for the Web

Content should be written as clearly and simply as possible and should avoid jargon and abbreviations. If abbreviations are used they need to be expanded on first use on each page or landing point. Be especially mindful of redundancy. Unclear or repetitive information can be frustrating for users who rely on screen readers.

Try to keep all your information on one page, instead of several. If the information needs to be outlined in several areas on the web, still keep all the information on one page, and link to it from the other pages. This way when changes happen, you only need to apply them in one specific area as opposed to many. Having redundant content on the website is what helps create conflicting information. Chances are, when updates are needed, they will be made in one area, but neglected in another.

As mentioned, a simple workaround to avoid this is to create a link to the main information page from the other misc. pages.

 

Use of Colour

Colour is an important asset in web design, being used to enhance aesthetic appeal, usability, and accessibility. However, some users perceive colour differently, thus colour should never be the only way of conveying information. Consider people using text-only, limited-color or monochrome displays and browsers will be unable to access information that is presented only in color.

  • Graphs and charts should always include accompanying data (numbers, text) that adequately convey what the visual represents.
  • Additional visual cues should be included for links or controls where colour alone is used to identify them. This includes underlining hyperlinks so they can be easily distinguished from surrounding text. 

 

Colour Contrast

While colour is vital to web design, it’s important to ensure all colours used have adequate contrast between the foreground and background to ensure text is distinguishable.

The WCAG 2.1 requires colour combinations to meet the following contrast ratios:

  • Level AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text.
  • Level AAA requires a contrast ratio of at least 7:1 for normal text and 4.5:1 for large text.
  • Large text is defined as 19 pixels (1.2 em) and bold or larger, or 24 pixels (2 em) or larger.

WebAIM’s Contrast Checker is a great tool for determining the accessibility of various foreground/background colour combinations. 

 

Heading Hierarchy

Headings (represented as < h 1 >, < h 2 >, etc. tags) were once primarily used as a stylistic choice. However, with focus shifting from design to function, headings must now operate primarily as a structural tool. These are especially important for those using screen readers.

With headings, remember the focus should be on logical hierarchy:

  • The title of your page should be the only heading using the tag. The tag is the most important in terms of hierarchy.
  • Ensure all subsequent headings follow a proper parent/child relationship.
  • Avoid skipping heading ranks as it can make the content confusing in terms of navigation. Different levels of subheadings should be underneath main headings, for example a H3 would be nested under a H2.
     

Good Heading Structure
H1 - Page Title

H2 - Section Heading
H3 - Subsection Heading 1
H3 - Subsection Heading 2

H2 - Section Heading
H3 - Subsection Heading
H4 - Subsubsection Heading
 

Bad Heading Structure
H1 - Page Title

H3 - Section Heading 1 (H2 has been skipped)
H4 - Subsection Heading

H1 - Section Heading (H1 is being used twice) 

 

Bypassing Blocks or Skipping Navigation Links

Consider that, each time the user with disabilities navigates to a new page within your website, they must tab through all navigation links and other ancillary content before getting to the main content area of the page. To make this experience less frustrating, it’s good practice to add a button to “Skip to Main Content”. There are a variety of ways to do this. For more information on creating skip navigation and code examples, visit WebAIM's "Skip Navigation" Links

 

Self-Describing Page Links

Ensure hyperlinks are self-describing and make sense out of context. While popular practice, links like “click here” or "learn more" do not provide any useful information to someone using a screen reader. Hyperlinks should be descriptive and link to nouns that are context-specific.
 

Good Links

Register for Health and Safety Seminar

Learn more about Equity, Diversity and Human Rights

Learn more about the Greater Sudbury Communit

Download the Accessibility Report (PDF)

 

Bad Links

Click Here to Register

Learn more about Equity, Diversity and Human Rights

More Info 

 

Alternative Text for Images

Providing text alternatives (alt text) for any non-text content is important. All images must have text alternatives that describe the information represented in them.

  • Alternative text should be concise and meaningful.
  • Typically limited to around one hundred characters or less.
  • Use punctuation and sentence structure.
  • Avoid beginning descriptions with "image of…" or "graphic of…" 
  • Contextually appropriate with surrounding information.


Modules also have the ability to add images, and as a result of a recent update, all modules now have alt text. When given the option it is important that you add alternative text to all images on your web pages.

For more information on proper use of alternative text concepts, please visit W3C's Images Tutorial. For a full list of success criterion for various non-text content types, please refer to W3C’s Non-text Content: Understanding Success Criterion 1.1.1

 

Images of Text

Images of text are often used to ensure a specific design style is achieved. However, if an author can use text (HTML, CSS) to achieve the same visual effect, they should present the information as text rather than using an image. When CSS is used correctly, it alone can be used to control the visual presentation of text in maintaining a design style while still being accessible to all.

For better understanding of proper use and exceptions, visit W3C’s Images of Text Tutorial

 

Forms and labels

Forms are used for a variety of different functions throughout a website—including search, login, registration, commenting, and purchasing.

  • Provide instructions to help users understand how to complete the form and individual form controls.
  • Use the element, and, in specific cases, other mechanisms (e.g. WAI-ARIA, title attribute etc.), to identify each form control.
  • Keyboard focus order should match the visual order of the form.
  • Notify users about successful task completion, errors, and provide instructions to help them correct mistakes.

For a complete overview for creating accessible forms, please refer to W3C’s Form Concepts Tutorial

 

Tables

Data tables are used to organize data with a logical relationship in grids. Accessible tables need HTML markup that indicates header cells and data cells and defines their relationship. 

Assistive technologies use this information to provide context to users. Tables should only be used for tabular data, not page layout.

  • Use table headers ( element) to markup all column or row headers, and data cells ( element) for content.
  • Define the scope of each header, indicating whether it’s a column or row header. The value of the scope attribute can either be “col” or “row”.
  • When possible, avoid merged cells and empty table headers.

Tables without structural markup to differentiate and properly link between header and data cells can create accessibility barriers. For more information, visit W3C’s Table Concepts Tutorial

 

PDF

Under the Web Content Accessibility Guidelines (WCAG) 2.0, PDF files are considered web content and become an extension of your website.

If the PDF file is a form, consider using Google Forms instead.
If the PDF file is a document, consider converting it into a web page instead.

If you absolutely need to upload a PDF, take a look at these useful materials on making existing PDFs accessible:

Remove any older/duplicate PDF you may have on the Assets Server. Prospective students can find outdated content through Search Engines, so it’s important that you remove anything that is no longer applicable. This will help reduce our overall PDF count as well.

It is important to note that PDFs can only be tagged in one language for accessibility, so be sure to create separate files for English and French content.

If you have older, outdated PDFs living on the Assets Server, please have them removed. Although they may not be linked on Laurentian.ca, users may still find them through search engines.

The fewer PDFs we have in our server, the better!

Test the Accessibility of a Website

There are a variety of free tools available in order to thoroughly test the overall accessibility of a website.

 

Manual Testing

Accessibility is not a wholly technical endeavour, because accessibility is primarily about the human experience. Manual testing is an important first step in determining the overall effectiveness of a website’s layout and design, and an easy way to find initial points of frustration.

Try to navigate a website using only a keyboard, using a combination of the “Tab” and “Enter” keys.

  • Are you able to access all links, buttons, menus, or interactive components such as accordion panels, pop-up navigation menus or carousels?
  • Are you able to pause an image carousel?
  • Can you see where your cursor is located on the page?
  • Does the cursor follow a logical path from top to bottom, left to right or does it jump around? 

 

Screen Reader Testing

A screen reader is a common way for persons with disabilities to access online content. Understanding how screen readers treat your website and content can provide valuable information in ensuring all visitors have the same experience. You’re also more likely to catch redundant or poorly crafted content when you’re forced to listen to it and not skim visually.

Try navigating a website using a screen reader with your monitor turned off. If you are using an Apple computer, you can try the built-in screen reader utility called VoiceOver, which can be found in the accessibility settings. If you are using Windows, you can download a free screen reader like NVDA.

Another great universally available tool for content editors and developers is ChromeVox, a Google Chrome extension.

While using a screen reader, here are some things you should be listening for:

  • When announcing the link to home (typically associated with the logo on the site) are you able to tell where the link directs you from what is being said? What about other links? Does what is read to you give context as to where it will lead?
  • If there is more than one menu, are you able to tell which menu you are on and what link you are on within that menu?
  • For all forms, are you able to tell what information is expected of you when you are asked to input text (i.e. does it speak something like “enter search terms”)
  • Is all of the on-page content read to you?
  • Does the alternative text of an image give appropriate context as to what the image is about/its value to the overall story? 

 

Automated Testing

There are many free tools, plugins, book-marklets and applications available to test the accessibility of a website. Although automated tools are great to determine compliance issues and errors from a content or developmental perspective, they should never be the only method used to validate conformance with accessibility guidelines. Accessibility is about the human experience.

Here are the tools Laurentian University recommends for automated testing: