Niagara College Canada

Logo of the NC Accessibility Hub NC Accessibility Hub

Skip Navigation
Search
Skip sections menu to article content

Web Design, Web Development and Web Content

Web accessibility should be considered during all 3 stages of creating a website, but the articles in this Web Accessibility training series will focus on Web Content Creation.

Web Design

Web design is what your website looks like. Websites are normally mocked-up in a program like Adobe Photoshop first so you can see exactly what each page will look like before the website is built. Following accessibility guidelines like colour contrast and font sizes during web design is important.

Web Development

Web development is what happens ‘under the hood’. It’s the underlying code that makes up your website. Following accessibility guidelines during web development is critically important. How your web developer builds your site and the Content Management System (CMS) or website builder that your developer sets up for you to interact with will define how well you can implement AODA guidelines during web content creation.

Web Content Creation

Web content and its creation, updating and maintenance, is the key to any successful website. This could be text content, but could also include things like images, videos, audio, animations, charts, graphs, or infographics. Following accessibility guidelines during web content creation is extremely important.

If you’re feeling overwhelmed…don’t worry! Our Web Accessibility training series articles have been written with web content creators in mind. Each article in the series clearly explains how to meet AODA through the guidelines and criteria that are relevant to web content creators.

Written for Web Content Creators

The intended audience of our Web Accessibility training series is web content creators. We expect that web content creators are working within a templated website environment which has been developed by someone else, like an ITS department in the case of a post-secondary institution, or a web design company.

We assume that the website you are working on is running on a Content Management System (CMS), and you are restricted by the editing tools and layouts provided to you. Specific screenshots and instructions will be provided based on the WordPress.org CMS (when applicable), however the concepts and strategies provided would be useful in many web authoring situations.

In some cases, we might include information that is more applicable to a web developer. In these cases, we’ve determined that it’s important for you to understand how something works so you can make good accessibility decisions when authoring your content.

We understand that it might not be possible to meet all the accessibility guidelines that we outline due to the restrictions of your web authoring environment. We encourage you to try your best with the tools that you have in the spirit of web accessibility for all. If you come across a guideline that is not possible to achieve, please reach out to your webmaster or web developer to discuss your options.

The Accessibility for Ontarians with Disabilities Act (AODA)

The Accessibility for Ontarians with Disabilities Act (AODA) became law on June 13, 2005, in Ontario. The AODA states that as of January 1, 2021, all public websites who meet the following criteria must be made accessible:

  • You are a designated public sector organization or a business or non-profit organization with 50+ employees.
  • You control your website either directly or through a contractual relationship.
  • Your website was published or significantly refreshed after January 1, 2012.

You can learn more about the specifics of the AODA on the Government of Ontario’s AODA website.

What makes a website accessible?

The AODA states that public websites must meet Web Content Accessibility Guidelines (WCAG) 2.0 at level AA except for the following 2 criteria:

  1. Live Captions (Success Criterion 1.2.4) — You are not expected to provide real-time captions of livestreamed video.
  2. Pre-Recorded Audio Descriptions (Success Criterion 1.2.5) — You are not expected to provide pre-recorded audio-described video. Audio-described video is when a narrator describes what is happening in the scene for the blind and visually impaired. Here is a YouTube demonstration of audio-described video.

At its core, web accessibility is achieved through multiple technologies working together, including:

  • Web browsers: For example, Chrome, Firefox, Edge or Safari.
  • Web authoring tools: For example, a CMS (Content Management System) like WordPress or Drupal, or a website builder like Squarespace or Wix.
  • Adaptive technologies: For example, screen readers, screen magnifiers, or voice recognition software.
  • Underlying website code.

When you create web content it is ‘marked up’ by special code called HTML (Hyper Text Markup Language). Your browser reads the HTML instructions it’s given to build the webpage that you see.

But… what if you couldn’t see it? This is where web accessibility comes in.

Adaptive technologies read the HTML code of your website directly, and then help the user interact with your website. For example, a screen reader might read the content of your website aloud, while a screen magnifier would make the text larger and easier to see. If the HTML code of your website isn’t written correctly then adaptive technologies won’t be able to read it correctly. For a user with access challenges, they might find it difficult or even impossible to interact with your website.

Remember: blindness or low vision is only one example of a disability that could impact a user’s ability to use your website. There are many situations — not just disabilities — that could make a user’s web browsing experience a challenge. Making your website accessible means innately improving everyone’s user experience.

Learn more about why making your website accessible is important.

What is WCAG 2.0?

Web Content Accessibility Guidelines (WCAG) provide recommendations for making web content more accessible for everyone. The AODA requires us to meet WCAG version 2.0.

WCAG guidelines focus on making content more accessible to a wide range of people with disabilities including blindness and low vision, deafness and hearing loss, limited movement, speech disabilities, photosensitivity, learning disabilities, and cognitive limitations (Web Content Accessibility Guidelines WCAG 2.1, 2018).

  • WCAG 2.0 Guidelines. The actual WCAG 2.0 Guidelines, including all principles, guidelines, success criteria and techniques.
  • WCAG 2.0 Quick Reference. Allows you to quickly filter and review all layers of WCAG 2.0.

Learn more about WCAG 2.0 in our article: WCAG 2.0 at-a-Glance.

How does WCAG help achieve web accessibility?

WCAG provide guidelines and examples of the best way to write website code to ensure that your website is easy to use for everyone. WCAG guidelines help adaptive technologies more easily interact with and read your site. It also makes your website easier to use in ways that you might not realize

If WCAG guidelines aren’t followed when building your website, your visitors might not be able to successfully…

  • browse your website using their keyboard. For example, hitting tab to proceed to the next entry in a form.
  • increase the size of the text on a webpage using their browser’s zoom settings.
  • turn on closed captioning when watching a video in a noisy room.
  • browse a webpage when their internet speed is slow.
  • view your website in bright sunlight.

Website Accessibility with Content Management Systems and Website Builders

Without the guidance of a professional Web Developer who is familiar with AODA, websites created using Content Management Systems and Website Builders may produce a website with underlying code that does not meet AODA standards.

Content Management Systems (CMS) and website builders help users create and manage websites without knowing code. WordPress is a well-known CMS — which is what Niagara College uses. Examples of common website builders include Wix and Squarespace.  These tools allow you to do some or all of the following:

  • Choose the look and feel of your website and set fonts and colours.
  • Create webpages and allow you to choose different layouts.
  • Add, edit, and remove content and images.
  • Allow you to sell products.
  • Integrate special features (ex. date countdown, social media connections).

CMS and website builders add a new layer — a user interface — between your website’s code and what appears on the page in your browser. You might use a drag and drop interface, for example, to lay out the elements and content on a webpage. The CMS or website builder would then write and output the website code for you.

These types of tools often create websites with poorly written code that would be difficult or impossible to use successfully by adaptive technologies. Often, these types of systems are guilty of creating websites that look the way you want but are not able to intelligently apply the guidelines needed to achieve an accessible website.

Regardless of platform, it is important that WCAG is considered at the web design and development stages. The CMS or website builder that you are using should be set up by your Web Developer to output accessible code as part of its theme or template and should ensure that content that is being output as part of your work as a content creator is accessible as well.

Accessibility Overlays

You may have seen an accessibility overlay before: often displayed as a small menu floating on the side of your screen when you visit a website. They usually have buttons to change the size of text on the screen, change the contrast, read the webpage aloud, and so on.

These overlay plugins are marketed as being a complete solution to meeting AODA. They’re sometimes offered as part of a pricy contract with a certificate that guarantees that your website is accessible and claim to automatically make all the revisions and additions necessary.

If you are considering using an accessibility overlay: don’t.

How do accessibility overlays work and where do they fail?

  • Overlays make changes and additions to a website’s code while it’s loading. They can make the accessibility of your website worse by breaking existing code.
  • They offer accessibility features that adaptive technology already has. For example, changing the colour contrast or text size of a webpage.
  • They are often difficult to find on-page using adaptive technology. They are simply another tool that visitors must learn to use.
  • They might introduce privacy issues. For example, including the overlay from a 3rd party vendor might allow them to load a tracking or data harvesting script that you don’t know about.
  • They add additional load time to your website.

According to Essential Accessibility (2021): “Accessibility overlay vendors will make countless false promises, guarantee your website will be fixed to meet 100% of […] WCAG requirements, and let you walk away thinking you’ve done your due diligence.” When in reality, accessibility overlays are only able to detect 20-30% of issues occurring on your website (The Many Pitfalls of Accessibility Overlays, 2021).

Overlay vendors will often reach out to unsuspecting businesses claiming that they’ve run an audit on their website, and surprise: apparently, they’ve scored an ‘F’! Don’t fall for their offer of a quick fix.

Often, overlays are marketed as cost-effective, quick solutions vs. the potentially expensive expert contribution of a competent accessibility-educated web developer who will work to build or correct your website through legitimate means. Overlays are simply a false promise — not only to you, but everyone who visits your website and deserves to interact with it in the way that works best for them.

Simply put, web accessibility doesn’t happen overnight, and a dedicated website build or rebuild may take months or longer.

Accessibility Overlays: Further Reading

The issue of vendors promoting accessibility overlays as a WCAG solution has become so frustrating to the accessibility community that dedicated articles and websites have been developed to help businesses and individuals understand the pitfalls of these types of products.

Working with Web Developers

The underlying code of a website is where the bulk of WCAG 2.0 guidelines are applied. While we’ll be focusing the articles on the NC Accessibility Hub website on web content creators, we’ve compiled a list of helpful resources for web developers below.

The Government of Ontario offers some tips about how to work with web developers to comply with AODA.

Web Developer Resources

Articles in the Web Accessibility Training Series

We welcome you to dive into the world of web accessibility through the other articles in our Web Accessibility training series:

Credits

  • Photo by Marco VDM via Getty Images. Used with permission.

References

About the AODA. Accessibility Services Canada. (2019, December 11). Retrieved January 9, 2022, from https://accessibilitycanada.ca/aoda/

How to make websites accessible. ontario.ca. (n.d.). Retrieved January 9, 2022, from https://www.ontario.ca/page/how-make-websites-accessible

Web content accessibility guidelines (WCAG) 2.1. W3C. (n.d.). Retrieved January 9, 2022, from https://www.w3.org/TR/WCAG2/#abstract

WCAG levels. WCAG Levels: Level A, AA and AAA Compliance. (n.d.). Retrieved January 9, 2022, from https://myaccessible.website/blog/wcaglevels/wcag-levels-a-aa-aaa-difference

The Many Pitfalls of Accessibility Overlays. (2021, December 8). ESSENTIAL Accessibility. Retrieved January 15, 2022, from https://www.essentialaccessibility.com/blog/the-many-pitfalls-of-accessibility-overlays

Is this page useful?

Hidden
Hidden
Back to Top