Skip to main content

WCAG Basics to Begin Your Accessibility Journey

10 min read
Four figures representing disabilities, proceeding in a row with website wireframes in the background.

ADA web accessibility compliance ultimately requires that developers get into the weeds of the 78 guidelines that make up WCAG 2.1. Visual checks and quick scans provide a solid starting point, however, and serve as key indicators of underlying accessibility violations. 

Here’s an overview of the essential factors to consider with developing or auditing a website for accessibility.

  • Contrast
  • Non-text content
  • Link purpose
  • Labels and instructions
  • Information and relationships
  • Keyboard navigation

 

Contrast

Contrast ratio refers to the luminance of the foreground text against its background. This guideline states that text and images with text need to have to have a contrast ratio of 4.5:1 for small text (less than 18 points, if not bold, and less than 14 points, if bold), and 3:1 for large text. For the highest level of compliance (AAA), which is not required in most instances, the contrast ratio for small text needs to be 7:1.

Tools for checking color contrast ratios include contrast checker and WEBAIM’s Color checker.

Sample Contrast Checker Output

Sample output from a color contrast checker tool

 

Content that does not consist of a sequence of characters, such as images and form controls,  is covered by non-text content guidelines. Non-text content needs to have a text alternative that serves verbally describes the image, otherwise known as “alt-text.”  If the image is decorative or only used for visual formatting, then it can have a null alt (alt=””) or implemented in a way that it can be ignored by assistive technologies, such as a screen reader.

Sample code for the following image:

<img src=”location/of/image.jpg” alt="Illustration of man sitting in wheel chair and woman standing against background projecting a checklist diagram.">

Illustration of a man in a wheelchair and a woman reaching out with website wireframes in the background

Link Purpose

Screen readers users should be able to determine the purpose of a link based on the text alone.

For this reason, generic link text such as “read more,” “learn more,” or “click here” is not WCAG compliant. To avoid confusing those who use screen readers, content editors also need to keep in mind that if the same link text is used more than one time on a page, the destination for those links needs to be the same.
 

Labels and Instructions

Clear instructions and labels need to be in place for controls that require user input. Instructions also need to provide specific formats, that indicate exactly how information such as dates, phone numbers, and email addresses need to be entered. 

Important points to keep in mind:

  • Labels should be properly associated to their specific fields
  • Related form elements should be contained in a fieldset and should have labels properly associated with them.
  • When input fields are compulsory they should be coded properly as required. Error messages should also be clear to users and contain instructions and sample formats on how to fill in the field properly.

 

Information and Relationships

The focus here is the semantic structure of the page as it appears to users of assistive technologies. 

Headings

Screen reader users rely on headings to navigate and scan content to understand the flow of information on a page. As such, headings should be logically structured within the H1 to H6 HTML hierarchy. There should only be one H1 heading on a page, and there should not be any skipping of the descending order of headings within that hierarchy. An H1 followed by an h2 might confuse a screen reader user into thinking that they skipped an important part of the content.

Tables

When a page contains a table or multiple tables, it is important that these tables be identified based on the data they contain. Tables should have captions that serve as the general description. It is sometimes an option to use  <summary> to supplement table descriptions, but this option is not widely supported by assistive technologies.

Keep the following points in mind concerning tables on a webpage: 

  • Layout tables should be avoided. When tables are used to format content, they might cause some confusion to screen reader users. Instead of using tables to format your content, use CSS.
  • Designate row and column headers to data tables using the <th> element. 
  • Associate data cells with the headers using the <scope> attribute.
  • Avoid nested tables. The more complicated the table, the more inaccessible it becomes.

Semantic Markups

Formatting is important for the look and feel of the page but the underlying code should contain the same information as the visual presentation of content. Headings should have proper heading markups. Lists should be marked with <ul>, <ol>, or <dl>. For emphasized texts use <strong>, <em>, <blockquote>, <code>, etc.

Landmarks

Landmarks provide another way for screen reader users to navigate a page. It has previously been recommended to use HTML5 and WAI-ARIA landmark roles together (e.g. WAI-ARIA role="navigation" on HTML5 'nav' elements) but with the widespread adoption of HTML5 this is no longer needed. There should be only one main landmark on the page, and all page content should be included in landmarks. 

The focus here is the semantic structure of the page as it appears to users of assistive technologies. 

Keyboard Navigation

All functions need to be keyboard accessible. This is because users with mobility issues may not be able to use a mouse or trackpad. The “Enter” key and “Space” bar needs to accommodate all functional navigation on the page. Also keep in mind, keyboard navigation is an important everyone, as the battery in a mouse can lose power.
 

There's Much More to Learn!

Promet Source is passionate about ensuring the accessibility of online experiences for people of all abilities, while helping clients to avoid ADA Accessibility legal action. We’re available to help in ways that include training, development, consultation, support, and workshops.  

Contact us today to let us know what we can do for you.

 

 

Donnabel Carato

Donnabel is truly a belle (as her name implies). She has been working with Promet as a Quality Assurance (QA) Analyst for more than 6 years. A consummate professional, she loves providing service with a smile to her clients and her projects.