Maximize content compatibility
WCAG Guideline 4.1 (AA) and success criteria
Compatibility in web accessibility ensures that content can be correctly interpreted and accessed by diverse devices, browsers and assistive technologies, both current and future. It allows people using different technologies to access and interact with the content without barriers.
Parse for code structure and syntax compliance (Level A, 4.1.1)
To ensure your web content is properly structured and follows the rules of the markup language you’re using, like HTML or XML, it needs to adhere to syntax guidelines. This not only means following syntax rules but also representing the content’s structure. For instance, using heading elements instead of relying solely on visual formatting.
Meeting requirements
Failing to meet these requirements may result in different browsers displaying the content inconsistently or not rendering it at all.
- Use complete start and end tags
- Properly nest elements
- Avoid duplicate attributes within elements
- Ensure unique IDs that are not repeated on the page
These considerations are specific to web content, but they also apply to digital content such as documents or software applications.
Tips to enhance code
When parsing, it is important to follow these tips to ensure web content quality:
- Use the correct DOCTYPE declaration at the beginning of your HTML document to indicate the version of browser you’re using
- Validate your markup with a validator tool to identify errors and ensure compliance with the markup language’s rules
- Test your content across various browsers and assistive technologies to ensure accessibility for a broad range of users
- Utilize semantic HTML elements like
<header>
,<nav>
,<main>
, and<footer>
instead of generic elements like<div>
, as this improves comprehension for both humans and machines - Consider implementing ARIA attributes (Accessible Rich Internet Applications) to convey the purpose or state of elements, especially for dynamic content. But use them sparingly as they can be complex and overuse can make content less accessible
To learn more visit Understanding SC 4.1.1.
Implement machine-readable name, role, and value (Level A, 4.1.2)
In accessibility, “programmatically determined” means that software can recognize an element, understand its purpose and support interaction with it. To meet this requirement, all user interface components must have a name and role that can be understood by software. This helps assistive technology gather information about the components and enable appropriate interaction.
For example, in a form, the ‘submit’ button can be named ‘submit’ and given the role of a ‘button’. This tells an assistive technology user that they are interacting with a button used for submitting the form.
Name, role and value exceptions
For images instead of using a name or role, you can use the ‘alt’ attribute. Non-interactive elements like lists that don’t require a name or role.
The term “programmatically set,” means that the software or program can set or change something without requiring a manual input.
For example, using a toggle button to adjust the colour contrast on a webpage. When the user toggles the button, the software ‘programatically sets’ the colour contrast to a higher or lower level, eliminating the need for manual adjustments each time.
Components should allow users to modify states and values. For example, in a form with a dropdown menu:
- State indicates the currently selected option
- Value represents the text options, such as ‘yes’ or ‘no’
- Label provides a description of the dropdown menu component
Users should also have the ability to modify any property that influences the component’s behaviour or appearance, like its size, colour, font or position.
Standard HTML controls meet these criteria if they’re used correctly. But, if you’re using custom controls or interface elements, you must give this essential information and allow for control by assistive technologies.
To learn more, please refer to Understanding SC 4.1.2.
Make polite status messages (Level AA, 4.1.3)
Status messages tell users the status of a system or process, such as an error message or progress update. Users need to be aware of important changes in content even when they’re not given focus. When avoidable, the messages should not interrupt the user.
The status messages must be recognized by software, meaning it needs to be coded as such. To do this, you can use ARIA (Accessible Rich Internet Applications), for example:
<div role=”status” aria-live=”polite”> Your message has been sent successfully. </div>
In this example the role attribute is set to ‘status’, indicating it’s a status message. The aria-live attribute is set to ‘polite’, which means the message should be presented to the user without interrupting their current task.
To learn more visit Understanding SC 4.1.3.