Accessibility ARIA Patterns

This deck is a focused review of web accessibility fundamentals, with an emphasis on ARIA patterns used to make interactive interfaces usable for everyone. It covers the basics of the a11y acronym, how accessibility differs from general usability, and the disability categories and conformance levels defined by WCAG 2.1. You'll also find targeted questions on contrast ratios, the POUR principles, the purpose of the ARIA specification, and the practical rules developers are encouraged to follow when adding ARIA to their markup. A few cards dive into accessible name calculations, helping you understand how assistive technologies resolve labels from native HTML, aria-label, and aria-labelledby.

It's well suited for front-end developers, UI engineers, designers, and QA or accessibility specialists preparing for interviews, certifications, or day-to-day implementation work. Beginners with some HTML familiarity will find it approachable, while experienced practitioners can use it to refresh the precise numbers and rules that are easy to forget between projects. If you're studying for a specific accessibility exam or onboarding into a team that cares about inclusive design, this deck gives you a tight, question-driven way to lock in the essentials.

Because the material mixes conceptual knowledge (like POUR principles and ARIA rules) with concrete specifications (such as exact contrast ratio thresholds), active recall will serve you well. Try answering each card out loud before flipping it over, and pay extra attention to the contrast ratio values, since they are the kind of detail that slips away without spaced repetition. Studying a handful of cards per day across a week or two is more effective than cramming everything at once, especially for the numeric guidelines.

One practical tip as you work through the deck: whenever you see a question about ARIA rules or accessible name precedence, pause and think of a real component in your own projects where that pattern applies. Connecting the cards to code you have actually written will make the answers stick and help you apply these patterns confidently in future interface work.

Web accessibility, often abbreviated "a11y" (a numeronym formed by "a" + 11 letters + "y"), refers to the practice of designing and developing websites so that people with disabilities can perceive, understand, navigate, and interact with them. This is related to but distinct from usability, which is the broader quality of a design being easy to use for everyone, including those without disabilities. Accessibility specifically targets barriers that disabled users encounter, while usability addresses general ease-of-use concerns across the entire audience.

The Web Content Accessibility Guidelines (WCAG) provide the foundational standards for web accessibility. WCAG 2.1 primarily addresses four disability categories: visual, auditory, physical/motor, and cognitive/neurological. The guidelines are organized around four principles, commonly remembered by the acronym POUR: content must be Perceivable, Operable, Understandable, and Robust. These principles structure all subsequent success criteria that web authors must satisfy.

WCAG defines three conformance levels: A (the lowest), AA (mid-level), and AAA (the highest), each imposing progressively stricter requirements. For color contrast, which is essential for users with low vision, WCAG specifies minimum ratios between text and its background. At level AA, normal-sized text requires a contrast ratio of at least 4.5:1, while large text — defined as 18 point or larger, or 14 point or larger when bold — requires only 3:1 because it is easier to read. At level AAA, normal text demands an even stronger ratio of 7:1 to accommodate users with more severe visual impairments.

The Accessible Rich Internet Applications (ARIA) specification defines a set of roles, states, and properties that developers can add to HTML elements to make web content and applications more accessible to assistive technology users. ARIA works alongside native HTML semantics, and its proper use follows a set of well-known rules. The first and most important rule states that if a native HTML element or attribute provides the semantics and behavior you need, you should use that rather than adding ARIA. Other rules require that all interactive ARIA controls be usable with the keyboard, that interactive elements always have an accessible name, and that you never apply role="presentation" or aria-hidden="true" to a focusable element or one with focusable descendants.

An accessible name is the text that assistive technologies announce for an element, computed from sources like native HTML labels, aria-label, and aria-labelledby. When multiple sources are present, they have a defined precedence: aria-labelledby wins over aria-label, which in turn wins over the native label or label-associated text. Using aria-labelledby is often preferable because it can reference visible text on the page, supporting translation and dynamic updates, while aria-label takes only a static string. aria-label and aria-labelledby differ specifically in that aria-label supplies a literal string while aria-labelledby references the id(s) of other elements whose text becomes the name.

ARIA attributes fall into three categories. A role tells assistive technology the type of widget or structure an element represents, such as role="button" or role="navigation". A state is an aria-* attribute conveying a dynamic condition that changes in response to user action, such as aria-expanded or aria-selected. A property is an aria-* attribute describing a relatively stable characteristic of an element, such as aria-label, aria-required, or aria-haspopup. Together, these attributes help construct the parallel accessibility tree that assistive technologies consult.

Landmark roles identify major sections of a page so screen-reader users can navigate to them quickly. Many map directly to HTML elements: a `