What is WCAG?

WCAG - Web Content Accessibility Guidelines.

Web Content Accessibility Guidelines (WCAG) were created with the goal of providing a single, shared standard for all website content accessibility that meets the needs of individuals, organisations and governments internationally. The key is to maintain the same experience for all website users, whether able, hearing-impaired, visually-impared or otherwise disabled.

How do we comprehensively meet WCAG standards? All website content and code must be:

  • Perceivable - Information and user interface components must be presentable to users in ways they can perceive.
  • Operable - User interface components and navigation must be operable.
  • Understandable - Information and the operation of the user interface must be understandable.

For further reference on what these points entail, please view the WCAG Quick Reference Guide.
 

Why is it important?

In 2012, a survey was completed in the U.S, which revealed that almost 20% of the American population is afflicted with some type of disability, 13% having a severe disability. Therefore, designing and developing WCAG compliant websites is by no means tailoring for a minority. Being insensitive to the needs of disabled web users will most definitely cause you to lose a significant portion of your target audience.

What does this mean in practice?

There are 4 main categories within this group.

  • Fine Motor Skills Impairment - This was the largest group within the statistics mentioned above. Using a mouse is very difficult for these people. Thus, ask yourself, 'Is the website navigable using only the keyboard? Are elements ordered in a way that eases usability? While graphics, images, videos and other forms of media may significantly improve the visual impression of the website, do any of these features increase the difficulty for such viewers to interact with it?'
  • Cognitive, Mental or Emotional Impairment - Are the main goals and sentiments of the website communicated in a way that is clear and simple to understand? What type of language and vocabulary is used? While of course not losing the professionalism and formality of the product, is it possible to simplify such elements to become more inclusive for cognitive, mental or emotionally impaired users? Are interactive elements positioned logically, so as to be easy to see, standing out from the surrounding content?
  • Visual Impairment - Does the website account for screen-readers? What tools are in place to make navigating the website easier for visually impaired users? Are all visual elements accurately described and labeled (for screen-readers) to make it easy for visually impaired users to realise their purpose? Is it possible for those whose vision is limited to increase the text size without breaking elements of the website?
  • Hearing Impairment - Are transcripts and / or captions provided for all audio and video media throughout the website? Do any pages rely on such elements to communicate their key points and if so, are any alternatives provided for users with hearing disabilities?

Accounting for these elements will have a major impact on the level of interaction users have with a website. WCAG compliance is imperative.
 

How does it work?

There are varying levels of WCAG compliance, A, AA and AAA. Each project will have its own needs and requirements and of course such elements as time and budget may limit the level of compliance for any given project. However, there are aspects of website development that if covered, will always ensure an intermediate level of WCAG compliance.

Best Practices for Typography and Features that require Custom HTML

Screen-readers require a certain level of readability in order to interpret your website correctly for the user. For example, website navigation appears within a containing element, just like all other HTML elements. There are various ways to create this container but often it may be tempting to use a div tag with a custom class of navigation to style the element. However, while there is nothing wrong with the functionality of the code in itself, screen-readers require you to be more specific. In this case, it would require you to use a nav tag with the role attribute set to navigation.

In the same way, many plugins, icon libraries and other custom features either use their own or old, unspecific tags. For example, by default, Font Awesome uses the i tag (used to explicitly italicise font) with a class name of fas fa-icon-name-here. However, for the sake of screen-readers, it is better to use the em tag, as this is more specific and more easily understandable for screen-readers. The same applies for strong tags instead of b tags, h1/h2/h3/h4/h5/h6 for headings and so on, aria-labels for any custom tags (looking at you, ion-icon) and so on.

Images

All images throughout the website should include alt attributes that accurately describe what any given image depicts or how the image contributes to the topic being discussed. If an image has no alt attribute, screen-readers may read aloud the entire file path within the src attribute, so even images that are only present to visually enhance the design of the website should be provided with empty alt attributes.

ARIA Roles

All major segments throughout a website (e.g. headings, navigation, forms, buttons, etc.) should be provided with the ARIA role attribute. This will make it clear for users with screen-readers to navigate a page.

For more information on ARIA Roles, click here.

ARIA States & Properties

Any visual/interactive elements throughout a website should be provided with aria-labels or descriptions to account for visually impaired users. Such attributes are especially useful if multiple images have the same label/description, as the aria-labelled-by and aria-described-by attributes allow you to assign one label or description to multiple HTML elements.

For more information on ARIA States and Properties, click here.

Video/Audio Media

For obvious reasons, hearing impaired users struggle to interact with video and audio media elements on a website. If the project budget allows for it, transcripts should be provided for all such media, being clearly available for hearing impaired users to view. Even if it doesn't, it is a simple task to provide an aria-described-by with a concise but matching description to cater for these users. If the media is embedded directly onto a page, it may also be asthetically pleasing to provide a subtle caption below it.

Forms

All form elements should be labelled. Please note that the placeholder attribute is not relevant to screen-readers, so always provide either a physical label above an input field or an aria-label that accurately describes it. Use label tags with the for attribute linked to the id of the input field for any physical labels. 

Keyboard Navigation

Those who have difficulties with fine motor skills may struggle with using a mouse, in many cases resorting to exclusive use of the keyboard to navigate websites. For this reason, tabindexes may need to be set for form fields, physical positioning of the HTML must be logical and allow for keyboard navigation and appropriate tags must always be used for relevant HTML objects (further outlined in 'Best Practices for Typography and Features that require Custom HTML').

Thank you for reading through this short summary of WCAG compliance practices. If you have any further questions, feel free to contact us via email or phone call, or click here to view a more comprehensive study of official WCAG standards.