Web Accessibility

This deck introduces the foundations of web accessibility, helping you understand why inclusive design matters and how to apply it in practice. You'll explore core concepts like the WCAG guidelines, the four guiding principles, and practical techniques such as writing meaningful alt text, using semantic HTML, ensuring keyboard accessibility, and maintaining sufficient color contrast. Together, these cards build a clear picture of what it takes to make websites usable for everyone, including people with disabilities.

It's a great starting point whether you're a web developer looking to write more inclusive code, a designer thinking about user experience, a content creator publishing online, or a product manager wanting to understand accessibility requirements. The questions are framed at an introductory level, so no prior experience with accessibility standards is needed, though basic familiarity with HTML will help some concepts click faster.

To get the most out of your study sessions, try connecting each card to a real example you've seen on the web, like noticing whether a site you use daily has proper focus indicators or descriptive link text. Many of these concepts build on one another, so reviewing the foundational cards before tackling the more detailed ones can make the material stick. Spacing your review over several short sessions rather than cramming will also help these principles become second nature when you're actually building or evaluating websites.

Web accessibility is the practice of building websites and applications that people with disabilities can perceive, understand, navigate, and use. It is not a niche concern but a quality discipline that improves inclusion, usability, legal compliance, and overall product quality for everyone. When teams treat accessibility as a cleanup task at the end of a project, they end up with fragile fixes that miss systemic issues; the most effective approach is to build accessibility checks into design, development, testing, and review from the very beginning.

The central international standard for evaluating digital accessibility is the Web Content Accessibility Guidelines, commonly known as WCAG, which is maintained by the W3C's Web Accessibility Initiative (WAI). WCAG is organized around four foundational principles, often remembered by the acronym POUR: content must be Perceivable, Operable, Understandable, and Robust. Each principle is supported by a set of testable success criteria grouped into three conformance levels. Level A is the minimum, Level AA is the target referenced by most regulations and represents practical, substantial coverage, and Level AAA is the highest standard that is often impractical to meet across an entire site.

Accessibility is not only an ethical and design issue but also a legal one in many jurisdictions. In the United States, the Americans with Disabilities Act (ADA) has been extended by courts to cover digital properties, and Section 508 requires federal agencies to make electronic content accessible, referencing WCAG 2.0 AA. In the European Union, the European Accessibility Act (EAA), which takes effect in 2025, requires digital products and services to meet accessibility standards. Because most major regulations point to WCAG AA, teams should treat that level as their baseline target and publish an accessibility statement that acknowledges the current status, known issues, and a contact path for users who encounter barriers.

The Perceivable principle states that information and user interface components must be presentable to users in ways they can perceive. This means providing text alternatives for images through alt text, supplying captions for video content, ensuring sufficient color contrast between text and backgrounds, and never relying on color alone to convey meaning. Perceivable design also extends to making content that does not break when users resize text or change spacing, since some readers need larger text or extra letter spacing to read comfortably.

The Operable principle requires that interface components and navigation must be operable by all users. Keyboard accessibility is the cornerstone of operability, since many people cannot use a mouse and rely on keys such as Tab, Shift+Tab, Enter, Space, and the arrow keys to interact with pages. Operable interfaces also avoid content that flashes more than three times per second to prevent seizure triggers, give users enough time to read content, and provide ways to pause or stop motion. Touch targets should be large enough to tap reliably, with WCAG 2.5.8 setting a 24 by 24 pixel AA minimum and 2.5.5 recommending 44 by 44 pixels at AAA.

The Understandable principle covers both information and operation: content must be readable and predictable, and interfaces must help users avoid mistakes. Plain language reduces cognitive load, headings and labels create predictable structure, and specific error messages tell users what went wrong and how to fix it rather than leaving them to guess. The Robust principle requires that content remains interpretable as technologies evolve, which means using valid markup, leveraging native HTML semantics where possible, and supplementing with ARIA only when no native element can express the right meaning.

Semantic HTML is the foundation of accessible markup. Using built-in elements like <button>, <nav>, <main>, <label>, and <table> conveys meaning and behavior to the browser and assistive technologies without any extra work. A <button>, for example, comes with keyboard support, focus behavior, and screen reader semantics by default, while a <div> styled to look like a button carries none of those guarantees. Whenever a native element can do the job, it should be used first; this is often called the first rule of ARIA: do not reach for ARIA when semantic HTML already provides the answer.

ARIA, the Accessible Rich Internet Applications specification, provides a set of attributes that can improve semantics when native HTML is not enough. ARIA is divided into roles that define what an element is, such as role="button", role="dialog", role="menu", role="tab", or role="alert", and states and properties that describe its current condition, like aria-expanded, aria-selected, aria-pressed, aria-disabled, aria-invalid, aria-required, aria-busy, aria-controls, aria-current, and aria-haspopup. Two attributes handle naming directly: aria-labelledby references the ID of an element whose text serves as the accessible name, while aria-label provides a string when no visible text exists. The accessibility name calculation follows a consistent precedence: aria-labelledby wins, then aria-label, then the native label such as a <label for> association or alt text, then the element's text content, and finally the title attribute as a last resort.

ARIA can also remove elements from the accessibility tree when they are purely decorative. aria-hidden="true" hides content from assistive technologies and is appropriate for redundant icons or visual flourishes, though content already hidden with display: none does not need an additional aria-hidden. The role="presentation" attribute similarly removes the implicit role of an element such as a layout <table>. Common misuse of ARIA, such as adding a role that conflicts with native semantics or using ARIA to add visual appearance rather than meaning, frequently makes interfaces less accessible rather than more. Because ARIA does not add behavior, a <div> with role="button" still needs keyboard handlers, a tabindex, and visible focus styling; native elements give all of that for free.

Keyboard accessibility is essential because many users, including those who are blind or have motor impairments, rely entirely on the keyboard to interact with the web. The tab order is the sequence in which focus moves through interactive elements via the Tab key, and ideally this order follows the natural DOM order so that visual layout matches logical progression. The tabindex attribute controls focusability: tabindex="0" makes an element focusable in DOM order, tabindex="-1" allows programmatic focus without including the element in sequential tab navigation, and positive tabindex values should be avoided because they disrupt natural order and are difficult to maintain.

Visible focus is critical because it tells keyboard users which element is currently active. Removing focus outlines or replacing them with an invisible alternative silently breaks the experience for keyboard users. The CSS :focus-visible pseudo-class improves on the older :focus selector by showing a focus ring only when the browser determines the user is navigating by keyboard, which keeps mouse interactions visually clean while still satisfying keyboard users. Modern focus indicators should be clearly visible and meet WCAG contrast requirements so they are easy to spot against any background.

Many components require explicit focus management because the browser cannot infer what should happen when content changes. When a modal opens, focus should move to the first focusable element inside, ideally the heading or a primary action, and a focus trap should constrain Tab and Shift+Tab to cycle within the modal. Pressing Escape should close the modal, and when it closes, focus should return to the element that opened it, preserving the user's place in the page. The native <dialog> element, opened with showModal(), handles much of this for free, including focus trapping, an inert backdrop, and Escape-to-close, while show() opens the dialog non-modally without trapping focus. Skip links are another essential focus tool: a hidden-until-focused link placed as the first focusable element on each page, usually pointing to a <main> landmark, lets keyboard users jump past repeated navigation directly to the main content.

Color contrast is the visual difference between text and its background, and it must be strong enough for content to be readable by users with low vision or in poor lighting. WCAG AA requires a contrast ratio of at least 4.5 to 1 for normal text and 3 to 1 for large text, defined as 18 point regular or 14 point bold. The AA standard also requires a 3 to 1 contrast ratio for non-text elements such as UI component borders, icons, focus indicators, and graphical objects. WCAG AAA is stricter, requiring 7 to 1 for normal text and 4.5 to 1 for large text, which can be hard to achieve with brand palettes. Tools such as the WebAIM Contrast Checker, axe DevTools, Stark, and the color picker in Chrome DevTools make it easy to verify ratios during design and development.

Color is also unreliable as the only signal because around 8 percent of men and 0.5 percent of women have some form of color vision deficiency, most commonly red-green. Status, errors, and meaning should always be reinforced with text, icons, or patterns so that users do not lose information when colors look the same. Required fields, for instance, can be marked with both an asterisk and aria-required="true"; validation states can pair a red border with an icon and an error message.

Motion, zoom, and theming preferences must also be respected. The prefers-reduced-motion media query lets sites honor an operating-system setting to minimize animation, and meaningful motion such as essential feedback can usually remain while decorative motion, parallax, and autoplay video are reduced. The flashing limit of no more than three flashes per second protects users with photosensitive epilepsy. Content must remain functional when zoomed to 200 percent and must reflow without horizontal scrolling at 320 CSS pixels wide, which is why text should use relative units like rem and em rather than fixed pixel sizes, and why the viewport meta tag should never disable user scaling through user-scalable=no or maximum-scale=1. Sites should also respect prefers-color-scheme for dark mode while ensuring both modes meet contrast requirements, and adapt to forced-colors mode such as Windows High Contrast through the forced-colors media query so that system colors are honored.

Accessible forms start with persistent, visible labels rather than placeholders. A <label for="id"> paired with its input, or a label that wraps the input, provides an accessible name, increases the click target, and remains visible while users type. Placeholder text, by contrast, disappears as soon as the user begins typing and typically fails contrast requirements, so it should never be the only label. Required fields should be marked both visually and with aria-required="true" or the native required attribute, and validation should run on blur rather than on every keystroke to avoid interrupting users in the middle of typing.

Error handling must be specific and well connected. Each field with an error should set aria-invalid="true" and use aria-describedby to point at the inline error message so screen readers announce the error when the field receives focus. A form error summary at the top of the form, listing each problem and linking to the offending field, lets keyboard users jump directly to what needs fixing without hunting. Success messages after submission can be placed in an aria-live="polite" region so screen reader users hear the confirmation without losing their place. Additional helpers such as autocomplete attributes for common inputs and inputmode hints on mobile keyboards further reduce friction for everyone.

Images need alt text that conveys the purpose or content of the image rather than its appearance, and screen readers already announce the word "image," so phrases like "image of" should be avoided. Decorative images should use an empty alt attribute, alt="", so assistive technologies skip them entirely. Complex images such as charts benefit from a brief alt plus a longer description referenced through aria-describedby or visible nearby. SVGs can be made accessible with a <title> child for the accessible name, an optional <desc> for longer description, and role="img" on the <svg> element. Document structure is equally important: a logical heading hierarchy that descends from h1 through h2 and h3 lets screen reader users scan pages the way sighted users skim; descriptive page <title> tags announce the topic on load; the <html lang> attribute enables correct pronunciation; and passages in other languages can be marked with a lang attribute on the wrapping element. Descriptive link text should make sense out of context, and unique IDs across the document prevent references like aria-labelledby from confusing the accessibility tree.

Complex components such as tabs, accordions, menus, and carousels require deliberate accessibility design because the browser cannot infer their interactive behavior. An accessible tab interface uses role="tablist", role="tab", and role="tabpanel", supports arrow-key navigation between tabs, and uses aria-selected to mark the active tab. An accessible accordion renders the header as a <button> with aria-expanded reflecting the open state and points aria-controls or aria-labelledby to the content panel. Carousels should announce the current slide, indicate total slide count, support keyboard navigation, and provide a visible pause control because auto-advancing motion can disorient users and conflict with prefers-reduced-motion. Popup menus should use role="menu" and role="menuitem" only when they behave like desktop application menus; typical website navigation should stay as plain landmark navigation.

Modal dialogs deserve particular care because they intercept the user's attention. The accessibility checklist for a modal includes moving focus into the dialog when it opens, trapping focus inside until it closes, supporting Escape to close, restoring focus to the trigger element on close, exposing role="dialog" with aria-modal="true", and pointing aria-labelledby at the dialog's title. The native <dialog> element opened with showModal() handles focus trapping, an inert backdrop, and Escape-to-close automatically, while show() opens the dialog non-modally for cases such as chat widgets where the rest of the page should remain interactive. Non-modal dialogs should still expose their semantics and accept keyboard focus appropriately.

Dynamic content that updates without a full page reload is invisible to screen readers unless it is announced through a live region. aria-live="polite" tells the screen reader to announce updates when it is idle, which is appropriate for non-urgent information such as form validation summaries or success messages. aria-live="assertive" interrupts current speech and is reserved for urgent alerts such as errors that block a workflow, and role="alert" implies both assertive and aria-atomic behavior in a single attribute. The aria-atomic property tells assistive technology whether to announce the entire region when any part changes or only the changed portion. Updates within a live region are announced in DOM order, and very rapid updates can be skipped, so the implementation should be deliberate. Developers can also inspect the browser's accessibility tree in Chrome DevTools under the Elements tab or in Firefox DevTools to verify how their markup is exposed to assistive technologies.

Accessibility testing combines automated tools with manual checks because automation catches only a fraction of real issues. Tools like axe DevTools, Lighthouse, WAVE, Pa11y, and Accessibility Insights are excellent for surfacing missing alt text, low contrast, missing labels, and duplicate IDs, but they typically detect only about 30 to 40 percent of accessibility problems. Keyboard logic, focus management, reading order, and screen reader behavior all require human judgment. A manual keyboard test navigates the entire UI with Tab, Shift+Tab, Enter, Space, arrows, and Escape, confirming that every control is reachable, every focus state is visible, and every action produces the expected result. A manual screen reader test, using NVDA on Windows, VoiceOver on macOS or iOS, TalkBack on Android, or JAWS in corporate environments, verifies that announcements match intent, focus order is logical, and dynamic updates are exposed correctly. Whenever possible, the best test is still with real users with disabilities, whose lived experience uncovers issues no tool can flag.

Accessibility audits bring these practices together into a structured review of UI patterns, markup, behavior, and testing results, with findings prioritized by user impact so that the most important fixes, those that prevent people from completing core tasks, are addressed first. Building accessibility from the start of design and development, often called shifting left, is dramatically cheaper than retrofitting, while last-minute drive-by fixes tend to be fragile and miss systemic issues. Teams benefit from accessibility personas that describe users with specific assistive technologies and constraints, because designing for concrete profiles reveals requirements that an abstract checklist might miss.

Cognitive accessibility is often overlooked but central to inclusive design. Plain language with short sentences, common words, and active voice reduces cognitive load for users with cognitive disabilities, second-language readers, and stressed users alike. A target reading age around grade six to eight works well for general public content, and tools like Hemingway can help simplify prose. Interfaces should reveal important information by default rather than hiding it behind interactions, because hidden details add cognitive load. WCAG 2.2, finalized in 2023, added criteria on focus appearance, dragging movements, target size minimums, consistent help, accessible authentication, and redundant entry to push this further, while the draft WCAG 3 is moving toward outcome-based scoring with broader scope including cognitive, mobile, and hardware contexts. Inclusive design, as articulated by Microsoft's toolkit and the curb cut principle, frames accessibility as part of designing for the widest range of human variation, recognizing that features originally built for disabled users, such as captions, dark mode, and curb cuts, end up benefiting everyone.