Table of Contents
WCAG ACCESSIBILITY PRINCIPLES:
There are 4 main guiding principles of accessibility upon which WCAG has been built. These 4 principles are known by the acronym POUR for perceivable, operable, understandable and robust. POUR is a way of approaching web accessibility by breaking it down into these 4 main aspects.
-
PERCEIVABLE
Content must be presented in ways that users can perceive, regardless of their sensory abilities. So each of us needs to be able to perceive the content without difficulties. That means that content is available to at least one of their senses. So, if you have a visual impairment, can you see it because you can make it large enough. Is there a good color contrast so all types of audiences can visually read it ? If you are blind, does your screen reader work with the content and read it out to you ? If the user is deaf and there’s some audio playing on the website, is there a text representation that you can read instead of listen to?
Ensure the output of web content is available through one or more of their senses:
- Sight
- Sound
- Touch
- Text Alternatives (Alt Text): Provide text alternatives (alt text) for non-text content such as images, videos, and icons. This helps users with visual impairments or those who use screen readers. Digital text is the most universally accessible format available. It can be converted into many other useful sensory formats such as text to speech, text to braille etc
- Multimedia Alternatives: Provide captions, audio descriptions or transcripts for audio and video content to help users who are deaf or hard of hearing otherwise your multimedia content on the website is less useful to deaf users.
- Adaptable Layouts: Content should be flexible enough to adapt to various screen sizes and devices. Users should be able to resize text without breaking the layout, for example.
- Color Contrast: Ensure sufficient contrast between text and background colors to make content readable for users with low vision or color blindness. WCAG guidelines suggest a contrast ratio of at least 4.5:1 for regular text.
- Visual and Audio Presentation: Avoid using visual or audio content in ways that could be inaccessible, like flashing images that could cause seizures (e.g., use of the “3 flashes or below” rule to prevent triggering seizures).
-
OPERABLE
Users must be able to interact with the content, whether they’re using a mouse, keyboard, voice commands, or other assistive devices. The other thing that needs to happen is that somebody needs to be able to operate the website or interface. So not everybody uses a mouse. Some people may have a mobility impairment i.e., they are forced to use a keyboard or may use speech recognition software. If a service doesn’t work with the input device that somebody is using, they are not going to be able to go to the page that they want to go to or submit the information that they need to submit. In this accessibility testing principle, assistive technologies are used.
Make the input methods of web content functionally available to a wide range of input devices such as
- Mouse
- Keyboard
- Touchscreen
- Voice recognition software
- Keyboard Accessibility: All interactive elements (e.g., buttons, forms, menus) should be navigable and usable via keyboard alone. This is critical for users who cannot use a mouse due to motor impairments.
- Focus Management: Ensure that the tab order of interactive elements is logical, and that focus is clearly visible so users can follow the path as they navigate.
- Timeouts and Controls: Provide users with the ability to pause or extend time limits on tasks or activities, especially for those with cognitive impairments or those using assistive technology.
- Accessible Forms: Forms should have clear labels, error messages, and controls to guide users through the submission process. This is especially important for users with cognitive impairments or those using screen readers.
- Seizure-Free Content: Avoid using content that may cause seizures or physical reactions, such as rapidly flashing lights or strobe effects.
-
UNDERSTANDABLE
Make the content & interface of the website easy to understand and operate for all users, including those with cognitive or learning disabilities and this is possible when complex jargons are avoided in the web content. So it’s all very well you receive that content but if you can’t understand it then you won’t be able to do what you need to do. So people have a range of cognitive abilities. Some people may struggle to read due to dyslexia, maybe on the autistic spectrum, so using things like clear & simple language that is easy to understand, making sure that interfaces are consistent and predictable are really important to making sure that somebody can understand the content and how to use your service.

- Clear and Simple Language: Use simple, concise language and define complex terms. Avoid jargon unless it’s necessary, and if used, provide explanations or glossaries.
- Predictable Navigation: Ensure that website and app navigation is consistent, intuitive, and predictable. Users should be able to anticipate where a link will take them or what action a button will perform.
- Error Prevention and Suggestions: When a user makes an error (e.g., in a form), provide clear, understandable error messages that help the user understand how to correct the mistake.
- Help and Instructions: Provide clear instructions for tasks that may require specific actions, such as filling out a form, so users know exactly what is required of them.
ROBUST
Content should be robust enough to work with a wide variety of user agents, OS, browsers including assistive technologies. This is because not all users use the same digital tools. The last bit is that it needs to be robust and that means it’s been built in such a way that it’s compatible with the technology that people are using. So if somebody is using a screen reader, does it work with that screen reader? If somebody is using an older browser, does it work with that older browser or other browser versions? Also, does it work on different network speeds ? Also does it work on smaller device screen sizes/resolutions.
- Compatibility with Assistive Technologies: Websites and applications should be tested with screen readers, magnifiers, speech recognition software, and other assistive devices. This ensures that the content is accessible to a wide range of users.
- Semantic HTML: Use well-structured, semantic HTML that provides meaningful information to assistive technologies. For example, using proper heading tags (<h1>, <h2>, etc.) to structure content helps screen readers understand the hierarchy of information.
- Dynamic Content: Ensure that dynamic content (e.g., content updated through JavaScript) is accessible and can be read by assistive technologies. This includes live regions, notifications, and other updates that may happen without page reloads.
- Cross-Browser and Device Support: Test your content on different browsers, devices, and platforms to ensure that accessibility features work universally. Accessibility should be consistent across environments.
SUMMARY OF THE FOUR ACCESSIBILITY PRINCIPLES:
If any one of these 4 principles don’t work then somebody won’t be able to have a successful interaction and complete the task that they are trying to do. So when you create a digital app/content, ask these 4 questions:- Perceivable: Can the user access the information with one of these 3 senses: sound, sight, touch ? If you have audio, is there a text transcript ? If you have images, do they include alt-text ? Make content accessible to all the senses (sight, sound, touch).
- Operable: Can the user interact with multiple input devices ? A good test for this would be to see if you can navigate the content using only a keyboard ? Ensure users can interact with and navigate the content, regardless of the input method (keyboard, mouse, etc.).
- Understandable: Can the user understand the information or how to use the component ? Ask, is the text and language of the content easy to read & understand ? Ensure content is clear and easy to understand.
- Robust: Is the component compatible with assistive technologies and different browsers ? Create content that works with current and future technologies, including assistive tools.
ABOUT WCAG

- WCAG stands for Web Content Accessibility Guidelines
- WCAG is a set of guidelines created by the World Wide Web Consortium (W3C) to help make web content more accessible for people with disabilities
- WCAG guideline versions are available as
- WCAG 1.0
- introduced in 1999
- WCAG 1.0 had 14 guidelines under POUR
- WCAG 1.0 is technology-specific i.e., WCAG 1.0 only applies to web content delivered using HTML
- WCAG 1.0 uses technologies such as HTML, CSS etc
- WCAG 2.0
- introduced in 2008
- WCAG 2.0 has 12 guidelines divided into 3 levels of conformance A, AA, AAA
- WCAG 2.0 is technology-neutral i.e., WCAG 2.0 can be applied to any type of web content, including web applications and rich media
- WCAG 2.0 uses newer technologies such as WAI-ARIA and SVG
- WCAG 2.0 provides more detailed guidance on how to create accessible content
- WCAG 2.0 has 61 success criteria
- WCAG 2.0 guidelines https://www.w3.org/TR/WCAG20/
- WCAG 2.1
- introduced in 2018
- WCAG 2.1 guidelines are related to mobile apps, as a consequence of mobile and tablet usage becoming more frequent than when the standards were first published in 2008 in WCAG 2.0
- WCAG 2.1 has 78 (61+17 new) success criteria
- WCAG 2.1 guidelines https://www.w3.org/TR/WCAG21/
- WCAG 2.2
- introduced in 2023
- WCAG 2.2 has 87 (78+9 new) success criteria
- WCAG 2.2 guidelines https://www.w3.org/TR/WCAG22/
- WCAG 3.0 [this is underway for implementation]
- documented in 2021 & not yet implemented
- WCAG 3.0 guidelines https://www.w3.org/TR/wcag-3.0/
- In WCAG 3.0, the conformance levels A, AA, AAA will be renamed as Bronze, Silver, and Gold, respectively
- A WCAG conformance level refers to the level at which a website or web-based application conforms to the Web Content Accessibility Guidelines , a highly impactful set of web accessibility standards. WCAG conformance levels are available as
- WCAG Level A [basic]
- WCAG Level AA [recommended]
- WCAG Level AAA [advanced]
- Accessibility scores are calculated by evaluating a website against established legal regulations and guidelines, using web accessibility testing tools, manual assessments, and user feedback.
- A good WCAG score typically ranges between 80%-100%
- WCAG 1.0