As a developer, it is incumbent on you that designs are implemented in an accessible, semantically correct way.
Understanding and adhering to the HTML standard is the best way to ensure accessibility for your web project. Browser and assistive technology developers similarly follow these standards, so making sure your project is semantically correct covers a large percentage of accessibility issues.
The ARIA (Accessible Rich Internet Applications) standard is a supplemental standard used in conjunction with HTML to help ensure accessibility in instances where semantic HTML either contains gaps, or cannot otherwise be used.
ARIA is most often used to indicate an element’s visual state to a user. Screen reader users are not made aware of changes on a web page without the developer implementing and updating appropriate ARIA, such as links that represent active pages, buttons that are pressed, elements that expand/collapse, etc.
HTML elements have implicit roles (e.g., <a> elements with an href attribute have a role="link" by default) however these roles may need to be updated according to the needs of the page (e.g., adding a role="button" to an <a> element to update the element to a semantic button). Semantic HTML should be used as much as possible for ease of maintenance, though some elements do not have an HTML tag equivalent (e.g., tabs and modals) thus making ARIA roles necessary.
If an element has multiple visual states, then there is likely an ARIA attribute to accomodate. For example, aria-pressed on a button to indicate whether its been pressed, or aria-current on an element that visually indicates the current page or step.
Often ARIA is needed to create relationships between disparate elements, such as form instructions to their input (using an aria-describedby attribute,) text that labels a dialog (using an aria-labelledby attribute,) or elements of a chat log (using a role="log".) If related elements are not associated via semantic HTML, there is likely an ARIA attribute to relate them.
A large part of ensuring pages are accessible relates to understanding the tools being used and how they output completed markup and styles.
Low-code development tools tend to require manually inserting ARIA attributes and accessible logic into interface elements. Understanding how these tools render the final outputted HTML is critical to ensuring correct semantics and accessible markup. Often the pre-built components in these tools must be eschewed for more accessible, custom-built components. Testing the components included with any development tool or framework for accessibility will often save a lot of headache if the components turn out to be inaccessible out of the box.
It’s most important for link text to make sense without the surrounding sentences or content. Learn more about accessible links.
Learn best practices for using animations and timed interactions in accessible ways and how to comply with WCAG 2.1.
ARIA (Accessible Rich Internet Applications) is a set of attributes that add accessibility information to HTML elements.
Learn how to create accessible forms that are are clear to understand and complete by all users.
Learn how to write accessible HTML using native elements, and why semantic structure is always the best first step in accessible design.
If not used thoughtfully, <iframe> elements can present accessibility barriers for users who rely on screen readers or keyboard navigation.