🌍 Front-end Web Development · flashcards

Front-end Web Development Accessibility Flashcards

51 question-and-answer cards covering Accessibility as it is examined in Front-end Web Development. 24 of them are printed below, taken from across the deck — no signup, no paywall on the preview.

51Cards in deck
24Free preview
6Syllabus topics
~199Chars per answer
FreePrice

24 sample cards from the Accessibility deck

Sampled from the end of the deck, so these are different cards from the ones shown on the syllabus page.

  1. What do the aria-atomic and aria-relevant properties control in live regions?

    aria-atomic (true/false) controls whether the entire region or only changed nodes are announced. aria-relevant specifies which change types (additions, removals, text, all) trigger announcements.

  2. What does aria-current indicate, and give example values.

    aria-current marks the current item within a set. Values: page (current page in nav), step, location, date, time, true, or false. Commonly used for the active link in a navigation menu.

  3. What is the purpose of aria-invalid on form fields?

    aria-invalid="true" indicates the value entered into a field has failed validation, signaling an error state to assistive technology. Often paired with aria-describedby pointing to the error message.

  4. What is sequential keyboard navigation, and which key drives it?

    Sequential keyboard navigation is moving focus through interactive elements one at a time using the Tab key (Shift+Tab to move backward), following the tab order (DOM order by default).

  5. What are the three meaningful values of tabindex and what does each do?

    tabindex="0" adds the element to the natural tab order in DOM position. tabindex="-1" makes the element focusable only programmatically (not via Tab). tabindex="1" (or any positive value) forces a custom tab order and is discouraged.

  6. Why is a positive tabindex value (e.g., tabindex="3") considered an anti-pattern?

    Positive values override the natural DOM tab order across the whole page, creating a confusing, hard-to-maintain focus sequence and easily causing keyboard traps. Use 0 and -1 only, and rely on DOM order.

  7. What is a keyboard trap, and why must it be avoided?

    A keyboard trap is when focus enters a component and cannot leave using the keyboard alone, stranding keyboard and screen reader users. WCAG 2.1.2 requires that focus can always move away via standard keys.

  8. Which keys are expected to activate buttons versus links?

    Buttons are activated by both Enter and Space. Links are activated by Enter only. Custom widgets with role=button must therefore respond to both Enter and Space.

  9. What keyboard pattern is expected within a composite widget like a menu, tablist, or radio group?

    The roving tabindex / arrow-key pattern: Tab moves focus into and out of the widget as one stop, while the Arrow keys move focus among the items inside it. Only one item has tabindex="0" at a time.

  10. What is the 'roving tabindex' technique?

    A focus-management method where exactly one child of a composite widget has tabindex="0" (the active item) and all others have tabindex="-1". Arrow keys move the 0 value to the newly focused item, keeping the group a single tab stop.

  11. What is a visible focus indicator and which WCAG requirement covers it?

    A visible focus indicator is the visual outline/styling showing which element currently has keyboard focus. WCAG 2.4.7 (Focus Visible) requires that keyboard focus be visible; you must not remove outlines without providing an equivalent.

  12. What is a 'skip link' and why is it important?

    A skip link is a (often initially hidden) link at the top of a page, like 'Skip to main content', that lets keyboard users bypass repeated blocks such as navigation. It satisfies WCAG 2.4.1 (Bypass Blocks).

  13. In a modal dialog, what two keyboard behaviors are required for accessibility?

    1) Focus trapping: Tab/Shift+Tab cycle only within the dialog while it is open. 2) Escape closes the dialog, and focus returns to the element that opened it. Focus should move into the dialog on open.

  14. What is the WCAG formula for contrast ratio between two colors?

    $$\text{Contrast Ratio} = \frac{L_1 + 0.05}{L_2 + 0.05}$$ where $L_1$ is the relative luminance of the lighter color and $L_2$ that of the darker color. Ratios range from $1\!:\!1$ to $21\!:\!1$.

  15. What is the formula for relative luminance used in WCAG contrast calculations?

    $$L = 0.2126\,R + 0.7152\,G + 0.0722\,B$$ where $R$, $G$, $B$ are the linearized (gamma-corrected) channel values. Green is weighted most heavily because the human eye is most sensitive to it.

  16. What are the WCAG 2.1 AA minimum contrast ratios for normal text and large text?

    Normal text requires a contrast ratio of at least $4.5\!:\!1$. Large text (at least 18pt, or 14pt bold) requires at least $3\!:\!1$. This is success criterion 1.4.3.

  17. What are the WCAG AAA contrast requirements for normal and large text?

    AAA (1.4.6) requires at least $7\!:\!1$ for normal text and at least $4.5\!:\!1$ for large text.

  18. What minimum contrast does WCAG require for non-text elements like UI components and graphics?

    At least $3\!:\!1$ against adjacent colors, per success criterion 1.4.11 (Non-text Contrast). This applies to button borders, form field outlines, focus indicators, and meaningful graphical objects.

  19. Why is using color alone to convey information a WCAG violation, and which criterion addresses it?

    Color-blind and low-vision users may not perceive the distinction. WCAG 1.4.1 (Use of Color) requires that color not be the only visual means of conveying information; add text, icons, patterns, or underlines as well.

  20. What is a screen reader, and how does a user typically interact with one?

    A screen reader is assistive software that converts on-screen content into synthesized speech or braille. Users navigate via keyboard shortcuts, moving by headings, landmarks, links, form fields, or reading linearly through the accessibility tree.

  21. Name three widely used screen readers and the platforms they run on.

    JAWS (Windows, commercial), NVDA (Windows, free/open-source), and VoiceOver (built into macOS and iOS). TalkBack is the built-in screen reader on Android.

  22. Why is correct heading structure (h1–h6) important for screen reader users?

    Screen reader users navigate by jumping between headings to scan and understand page structure. Headings must be used semantically and in a logical, non-skipping hierarchy, not chosen for visual size.

  23. What makes good alt text for images, and how should decorative images be handled?

    Good alt text concisely conveys the image's meaning or function in context, without 'image of' boilerplate. Decorative images should have an empty alt (alt="") so screen readers skip them; functional images describe the action.

  24. How can content be made visually hidden but still available to screen readers?

    Use a CSS 'visually-hidden' / 'sr-only' utility (clip the element to a 1px area, off-screen positioning, no display:none) so it stays in the accessibility tree. Avoid display:none or visibility:hidden, which remove it from screen readers entirely.

What this deck covers

The Accessibility deck follows the Front-end Web Development Accessibility syllabus — 2 chapters and 6 topics — so questions land on material that is genuinely examinable rather than trivia around it. That works out to roughly 25.5 cards per chapter.

Answers are written to be recallable, not just readable — averaging about 199 characters, which is long enough to carry the reasoning and short enough to say out loud.

A deck like this earns its keep on the second and third pass. Read the syllabus first so you know the shape of the subject, then use the cards to find the specific facts that have not stuck.

Accessibility flashcards FAQ

How many Accessibility flashcards are in this Front-end Web Development deck?

51 cards. This page previews 24 of them, sampled evenly across the deck so you can judge the difficulty before installing anything.

Are these Front-end Web Development flashcards free?

Yes. The preview here is free to read with no signup, and the full 51-card deck is free inside the Examius app.

What do the Accessibility cards cover?

They follow the Front-end Web Development Accessibility syllabus — 2 chapters and 6 topics — so the questions track what is actually examinable.

How should I use these flashcards?

Read the syllabus first so you know the shape of the subject, then drill the deck. Examius schedules each card with spaced repetition, so cards you keep missing come back sooner and ones you know drift further apart.