Front-end Web Development Accessibility Syllabus

Accessibility syllabus — full chapter and topic list

Expand any chapter to see its topics and sub-topics. This is the whole examinable outline for Accessibility in Front-end Web Development, not a summary of it.

1. 1

   ARIA

   3 topics

   • Roles
   • Properties
   • States
2. 2

   Best Practices

   3 topics

   • Keyboard Navigation
   • Color Contrast
   • Screen Readers

Accessibility flashcards for Front-end Web Development

25 of 51 cards from the Accessibility deck — real questions with worked answers.

1. What does ARIA stand for, and what is its purpose?

   ARIA stands for Accessible Rich Internet Applications. It is a set of HTML attributes that supplement native semantics to make dynamic, custom web content accessible to assistive technologies like screen readers.

2. In ARIA, what is the distinction between a role, a property, and a state?

   A role defines what an element is (e.g., button, dialog). A property defines a characteristic that is usually static (e.g., aria-label, aria-required). A state defines a condition that can change at runtime in response to user interaction (e.g., aria-checked, aria-expanded).

3. What is the First Rule of ARIA Use?

   If you can use a native HTML element or attribute with the semantics and behavior you require already built in, do so instead of repurposing a generic element and adding an ARIA role. Native elements are preferred over ARIA.

4. What is an ARIA 'role' and what does it communicate to assistive technology?

   A role is an attribute (role="...") that defines the type or purpose of a UI element, telling assistive technology how the element behaves and what to expect (e.g., role="button" announces it as a clickable button).

5. Name the five categories of ARIA roles.

   1) Document structure roles, 2) Widget roles, 3) Landmark roles, 4) Live region roles, and 5) Window roles (abstract roles also exist but are not used by authors).

6. What are ARIA landmark roles, and give four examples.

   Landmark roles identify major page regions so users can navigate between them. Examples: banner, navigation, main, complementary, contentinfo, search, region, form.

7. Which native HTML5 elements have implicit landmark roles equivalent to ARIA landmarks?

   <header> = banner, <nav> = navigation, <main> = main, <aside> = complementary, <footer> = contentinfo, and <form>/<section> map to form/region when labeled.

8. What ARIA role turns a generic element into something announced as a clickable button, and what else must be added for full equivalence?

   role="button". To match a native button you must also add tabindex="0" for focusability and key handlers for Enter and Space to trigger activation.

9. What are ARIA widget roles? Give examples.

   Widget roles define interactive UI controls. Examples: button, checkbox, radio, slider, tab, tabpanel, menu, menuitem, dialog, tooltip, switch, combobox, listbox, option, treeitem.

10. What is the role 'alert' used for, and how does it differ from role 'status'?

    role="alert" is a live region for important, time-sensitive messages; it has implicit aria-live="assertive" and interrupts the screen reader. role="status" is for less urgent updates with implicit aria-live="polite", announced when the user is idle.

11. What does the presentation/none role do to an element?

    role="presentation" (or role="none") removes the element's implicit semantics from the accessibility tree, so assistive technology ignores its role while still exposing its content/children. Useful for layout tables or stripping default semantics.

12. What is the accessibility tree?

    The accessibility tree is a structure the browser derives from the DOM, containing accessible objects with their roles, names, states, and properties. Assistive technologies read this tree rather than the raw DOM.

13. Define the ARIA property aria-label and when to use it.

    aria-label provides an accessible name as a string directly on an element. Use it when there is no visible text label, e.g., an icon-only button: <button aria-label="Close">.

14. What is the difference between aria-label and aria-labelledby?

    aria-label takes a literal string as the accessible name. aria-labelledby references the id(s) of other visible element(s) whose text becomes the accessible name. aria-labelledby takes precedence over aria-label when both are present.

15. What does aria-describedby do?

    aria-describedby references the id(s) of element(s) that provide a longer description or supplementary information about the element, announced after the accessible name (e.g., linking a form field to its help/error text).

16. What is the accessible name computation precedence (highest to lowest)?

    1) aria-labelledby, 2) aria-label, 3) the element's native labeling mechanism (e.g., <label>, alt, or content text), 4) title attribute as a last resort.

17. What does the property aria-required indicate, and how does it relate to the native required attribute?

    aria-required="true" tells assistive technology that user input on a form field is required. With native HTML form controls the required attribute is preferred; aria-required is for custom widgets without native required support.

18. What does aria-haspopup signal, and what values can it take?

    aria-haspopup indicates that an element can trigger a popup. Values: true/menu, listbox, tree, grid, dialog, and false. It tells users a secondary element will appear on activation.

19. What is the purpose of the aria-controls property?

    aria-controls identifies (by id) the element(s) whose contents or presence are controlled by the current element, e.g., a tab pointing to the tabpanel it shows, or a button to the region it expands.

20. What does aria-checked represent, and what are its possible values?

    aria-checked is a state for checkable widgets (checkbox, radio, menuitemcheckbox, switch). Values: true, false, and mixed (for indeterminate/tri-state checkboxes).

21. What does aria-expanded indicate and on which elements is it used?

    aria-expanded (true/false) indicates whether a collapsible element controlled by the current element is currently expanded or collapsed. Used on disclosure buttons, accordions, menu buttons, comboboxes, and tree nodes.

22. What is the difference between aria-hidden="true" and the HTML hidden attribute / display:none?

    aria-hidden="true" removes the element and its children from the accessibility tree but keeps it visually rendered and possibly focusable. hidden / display:none removes it from both the visual layout and the accessibility tree.

23. Why is putting aria-hidden="true" on a focusable element a problem?

    It hides the element from screen readers while keeping it in the tab order, creating a 'phantom' focus where keyboard users land on an element that is not announced. Hidden interactive elements should also be removed from the tab order.

24. What does the aria-disabled state do, and how does it differ from the native disabled attribute?

    aria-disabled="true" tells assistive technology the element is perceivable but currently disabled; unlike native disabled, it does NOT prevent focus or block events, so you must handle that behavior yourself.

25. What does aria-selected represent and where is it used?

    aria-selected (true/false) is a state indicating the selected item in a set of related elements such as tabs (role=tab), options in a listbox, gridcells, or rows.

See more Accessibility flashcards →

Planning Accessibility for Front-end Web Development

Accessibility (Front-end Web Development) FAQ