Accessible interface components
You build components such as menus, tabs, dialogs, accordions and notifications that follow ARIA patterns and keyboard expectations, and test them with a screen reader.
Level 301 · 15 lessons · 12 practice labs
Lessons
Name and state
- How the accessible name is computed
- Roles, states and properties
- Inspecting the accessibility tree
- Short task: give the icon buttons a name
Component patterns
- Disclosure and accordion
- Tabs and arrow-key navigation
- Modal dialogs: the focus trap and returning focus
- The menu button
- An autocompleting search box
- Live regions and notifications
- Short task: repair an inaccessible dialog
Dynamic interfaces
- Page changes and focus in a single-page app
- Complex data tables
- Keyboard alternatives to drag and drop
- Capstone: an accessible booking wizard
Practice labs
- Find unnamed controls in the tree: Inspect a text editor toolbar's accessibility tree and list the controls that have no name.
- Convey toggle state with ARIA: Add aria-pressed and aria-checked to toggles that show on/off and selected state only with CSS classes.
- Resolve conflicting name sources: Align the computed names with the visible text in a card list where aria-label, aria-labelledby and visible text contradict.
- Make an FAQ accordion accessible: Make an FAQ accordion keyboard usable by adding buttons, aria-expanded and aria-controls.
- Add arrow-key navigation to product tabs: Add arrow-key, Home and End navigation with roving tabindex to product detail tabs.
- Build an account menu button from scratch: Build a button that opens an account menu completely, including keyboard use, focus management and closing with Escape.
- Announce cart updates with a live region: Announce the visual "added to cart" notice to screen readers too with aria-live.
- Make search suggestions keyboard-selectable: Make a city search box's suggestions navigable with the arrow keys and announced, using aria-activedescendant.
- Tame noisy announcements: A market panel updating every second floods the screen reader; reorganise its live regions by priority and frequency.
- Add header relations to a timetable: Add scope and headers relations to a timetable with a two-row header.
- Add a keyboard path to drag and drop: Build a button-based, announced keyboard alternative for moving cards on a task board.
- Fix lost focus in an admin panel: Move focus to sensible places in a single-page admin panel that loses focus when a filter is applied or a record deleted.
About this course
You build components such as menus, tabs, dialogs, accordions and notifications that follow ARIA patterns and keyboard expectations, and test them with a screen reader.
What you will learn
- Name and state
- Component patterns
- Dynamic interfaces
Prerequisites
You should be comfortable with the level 101 and 201 topics of the same path.
Lab environment
Lessons run on your own Kali Linux desktop in the browser, with the tools ready in their windowed interfaces. Nothing to install; a computer screen is recommended.
Frequently asked questions
- Is this course right for my level?
- The course is at level 301; it assumes you know the topics of the lower-level courses.
- Is there anything to install?
- No. Every lesson runs in your own lab environment that opens in the browser.
- How do lessons work?
- Each lesson has 8 to 10 steps and a short quiz. Early steps show the command to type, later steps give less help; if two attempts fail, the solution opens.
- Can I try it for free?
- Yes. The first three lessons of every course are free.