ARIA Roles and Attributes: WAS Exam Practice Questions

Introduction: Why ARIA Matters on the WAS Exam

WAI-ARIA - the Web Accessibility Initiative's Accessible Rich Internet Applications specification - is one of the most heavily tested topics on the IAAP Web Accessibility Specialist (WAS) exam. Whether you are working through a WAS Practice Test: Free Web Accessibility Specialist Questions 2026 or diving into the official Body of Knowledge, you will find ARIA concepts woven through both Domain 1 (Creating Accessible Web Solutions) and Domain 2 (Testing and Evaluation). Understanding when to use ARIA, how to apply it correctly, and - critically - when not to use it at all can be the difference between passing and failing the exam.

This article delivers targeted web accessibility specialist exam questions focused exclusively on ARIA roles, properties, states, and live regions. Each question is followed by a detailed explanation tied directly to the October 2024 Body of Knowledge. Use these questions alongside a full WAS exam practice platform to build the confident, application-level knowledge the IAAP exam demands.

ARIA Fundamentals You Must Know

Before diving into practice questions, a brief grounding in ARIA architecture will sharpen your ability to eliminate wrong answers quickly. WAI-ARIA 1.2 defines three categories of additions to HTML: roles, properties, and states. Roles describe what an element is (e.g., role="dialog"). Properties describe characteristics that do not change during a user session (e.g., aria-label, aria-required). States describe dynamic conditions that change in response to user interaction (e.g., aria-expanded, aria-checked).

The single most important ARIA rule - Rule 1 of ARIA - states: Do not use ARIA if a native HTML element already provides the same semantics and behavior. This rule surfaces repeatedly in WAS certification practice questions because many candidates assume more ARIA is always better. The exam will test your ability to recognize when a native <button>, <nav>, or <input type="checkbox"> is preferable to a custom widget with extensive ARIA markup.

Practice Questions: ARIA Roles

Question 1

A developer builds a custom tab interface using <div> elements. Which combination of ARIA roles correctly describes the container and individual tabs?

1. role="tablist" on the container and role="tab" on each tab button
2. role="menu" on the container and role="menuitem" on each tab button
3. role="list" on the container and role="listitem" on each tab button
4. role="navigation" on the container and role="link" on each tab button

Correct Answer: A. The ARIA tab pattern requires role="tablist" on the container element, role="tab" on each individual tab, and role="tabpanel" on each content panel. Menu and menuitem are for navigation menus, not tab interfaces. Using list/listitem removes the tab semantics entirely. Navigation/link implies a page-level navigation landmark, which is semantically incorrect for a tab widget.

Question 2

Which ARIA role should be applied to a modal dialog overlay that traps focus and requires user interaction before the background content can be accessed?

1. role="alertdialog"
2. role="dialog"
3. role="alert"
4. role="region"

Correct Answer: B. role="dialog" is the correct role for a modal requiring user action. Use role="alertdialog" only when the dialog contains an urgent message requiring user acknowledgment (e.g., a destructive confirmation). role="alert" is a live region for short, important messages - not an interactive container. role="region" is a landmark, not a modal construct.

Question 3

A developer uses role="presentation" on a data table. What is the accessibility impact?

1. The table remains fully accessible to screen readers
2. The table structure (rows, cells, headers) is hidden from the accessibility tree
3. The table is visually hidden but still announced
4. Column headers are preserved but row headers are removed

Correct Answer: B. role="presentation" (also role="none") removes an element's implicit ARIA semantics from the accessibility tree. On a data table, this means the browser strips table, row, and cell roles - rendering the structure meaningless to assistive technologies. This is appropriate only for layout tables, never for data tables with meaningful structure.

Practice Questions: ARIA Properties and States

Question 4

A form field collects a user's email address and is required. There is no visible label, but a placeholder reads "Enter your email." Which ARIA technique is most accessible?

1. Add aria-placeholder="Enter your email"
2. Add aria-label="Email address" and aria-required="true"
3. Add role="textbox" to the input
4. Add title="Enter your email"

Correct Answer: B. aria-label provides an accessible name when no visible label is present. aria-required="true" communicates the mandatory nature to assistive technology. Placeholders disappear on input and have poor contrast in most browsers. The title attribute is a poor substitute because it is typically only exposed on hover, which is inaccessible to keyboard and touch users.

Question 5

When should aria-describedby be used instead of aria-labelledby?

1. When providing the primary accessible name for an element
2. When providing supplementary descriptive information beyond the accessible name
3. When hiding content from sighted users
4. When associating a label element with an input

Correct Answer: B. aria-labelledby sets the accessible name - the primary identifier announced by screen readers. aria-describedby provides an additional, longer description read after the name and role. For example, a password field might have an aria-label of "Password" and an aria-describedby pointing to a paragraph explaining password requirements.

Question 6

A custom accordion component uses a <div> as the toggle button. The accordion panel is currently collapsed. Which attribute and value correctly communicate this state?

1. aria-hidden="true" on the button
2. aria-expanded="false" on the button
3. aria-selected="false" on the button
4. aria-pressed="false" on the button

Correct Answer: B. aria-expanded communicates whether a widget that controls another widget is expanded or collapsed. It is the correct state for accordions, dropdowns, and tree items. aria-selected is for selectable items within a widget (e.g., tabs, options). aria-pressed is for toggle buttons. aria-hidden on the button would remove the button from the accessibility tree entirely - the opposite of what is needed.

Practice Questions: Live Regions and Dynamic Content

Live regions are among the most nuanced ARIA topics on the IAAP WAS exam. They allow screen readers to announce dynamic content changes without the user moving focus. The exam tests both correct implementation and common failure modes.

Question 7

A web application displays a success notification after a form is submitted. The notification appears in a <div> that was empty on page load. Which ARIA attribute ensures screen reader users hear the message?

1. role="alert" - the message is injected into the div after submission
2. aria-hidden="false" - toggled when the message appears
3. role="status" with the content pre-populated in the div on page load
4. A - inject into an existing live region present since page load

Correct Answer: D. The most reliable pattern is to have the live region element present in the DOM on page load (even if empty) and then inject content dynamically. Both A and D describe this, but D clarifies the critical nuance: the live region container must already exist in the DOM when the page renders. Creating a live region element and immediately injecting content is unreliable across browser/AT combinations. role="alert" is appropriate for important, time-sensitive messages and uses aria-live="assertive" implicitly.

Question 8

What is the difference between aria-live="polite" and aria-live="assertive"?

1. Polite regions are announced immediately; assertive regions wait for a pause in speech
2. Assertive regions interrupt current speech immediately; polite regions wait for a pause
3. Polite regions are only announced once; assertive regions repeat continuously
4. There is no functional difference - both are equivalent in modern screen readers

Correct Answer: B. aria-live="assertive" causes screen readers to interrupt whatever they are currently announcing to deliver the new content immediately - appropriate only for critical alerts. aria-live="polite" queues the announcement for the next available pause in speech - appropriate for status messages, search results, or progress updates. Overusing assertive live regions creates a chaotic, unusable experience for screen reader users.

Advanced ARIA Practice Questions

Question 9

A tree view widget contains nested items. Which ARIA attributes are required to communicate that a parent node has 5 child nodes and is currently expanded?

1. aria-expanded="true" and aria-setsize="5"
2. aria-expanded="true" and aria-owns pointing to the child group
3. aria-expanded="true", aria-posinset, and aria-level
4. aria-expanded="true" on the parent node; child count is communicated implicitly

Correct Answer: B. In a tree widget, aria-expanded on the parent node indicates open/closed state. If the DOM structure doesn't implicitly convey the parent-child relationship (e.g., the children are not nested directly inside the parent element), aria-owns can explicitly associate parent and child nodes. aria-setsize and aria-posinset describe position within a set, while aria-level describes nesting depth - all useful but secondary to the expanded state and ownership relationship.

Question 10

Which statement about aria-controls is most accurate for the current state of assistive technology support?

1. It is universally supported and reliably announced by all major screen readers
2. It has inconsistent support across screen readers and should not be relied upon as the sole means of communicating relationships
3. It is deprecated in ARIA 1.2 and should not be used
4. It only works when combined with aria-owns

Correct Answer: B. aria-controls is defined in the ARIA specification but has poor and inconsistent support across real-world screen reader and browser combinations. The WAS exam tests practical knowledge of AT support, not just specification compliance. Candidates should know that proximity in the DOM, correct focus management, and visible indicators of relationships are more reliable than aria-controls alone.

Common ARIA Anti-Patterns Tested on the Exam

The WAS exam consistently includes questions designed to test whether you can identify incorrect ARIA usage. Here are the most frequently tested anti-patterns:

ARIA Topics in the WAS Exam Domains

ARIA Topic	Domain 1 Relevance	Domain 2 Relevance
Landmark Roles	Custom layout and page structure	Manual screen reader testing
Widget Roles (tab, dialog, tree)	Custom interactive components	Keyboard and AT evaluation
aria-label / aria-labelledby	Accessible naming patterns	Automated and manual audits
aria-expanded / aria-selected	State management in JS widgets	Identifying state announcement failures
Live Regions	AJAX and dynamic content	Evaluating dynamic content accessibility
aria-hidden	Managing decorative content	Testing focus and AT exposure
aria-required / aria-invalid	Accessible form design	Form evaluation and error identification

For a broader look at how ARIA fits into your overall preparation strategy, the WAS Exam Study Guide: How to Prepare in 40-80 Hours provides a structured 40-80 hour study plan that allocates appropriate time to each domain and topic area.

Study Tips for ARIA on the WAS Exam

Memorizing ARIA attributes in isolation is insufficient for the IAAP WAS exam. The exam tests application and evaluation, not just recall. Here is how to build exam-ready ARIA knowledge:

• Read the ARIA Authoring Practices Guide (APG): The ARIA APG provides canonical patterns for every major widget type - tabs, dialogs, carousels, menus - and is directly aligned with WAS exam expectations.
• Test with real assistive technologies: Set up NVDA with Firefox and VoiceOver with Safari. Try navigating custom widgets and observe exactly what is announced. Hands-on testing is irreplaceable for Domain 2 questions on evaluation methodology. The article on Keyboard Accessibility and Screen Reader Questions for the WAS Exam covers this AT testing layer in depth.
• Practice identifying anti-patterns: Use browser developer tools to inspect accessibility trees. Find live sites with ARIA errors and diagnose them. This mirrors real exam scenario questions.
• Use the accessibility tree view in DevTools: Chrome, Firefox, and Edge all have built-in accessibility tree inspectors. Observing how browsers compute accessible names and expose ARIA attributes builds intuition that translates directly to exam performance.
• Do mock exams under timed conditions: Visit the WAS exam practice platform to complete full-length timed simulations. Timed practice reveals whether your ARIA knowledge is fast enough for the real exam format.

ARIA knowledge is also a prerequisite for understanding automated testing tools. Understanding which ARIA violations tools like axe, WAVE, and Lighthouse can detect - versus which require manual evaluation - is a key part of Domain 2. The Accessibility Testing Methodology: WAS Practice Questions article covers this intersection thoroughly.

If you are early in your certification journey and considering whether to sit the WAS exam directly or start with the foundational CPACC credential, the WAS vs CPACC: Which IAAP Accessibility Certification First? article provides an honest comparison of both pathways, including how technical your background needs to be to succeed on the WAS.

The demand for WAS-certified professionals is also accelerating rapidly due to the European Accessibility Act. Understanding the regulatory context behind the exam can sharpen your motivation and help you understand why certain technical standards (like ARIA compliance under EN 301 549) are emphasized on the exam.

For exam format details, scoring thresholds, and registration guidance, see the comprehensive WAS Certification Exam Guide: Format, Topics, Pass Rate and Tips, which covers everything from the number of scored vs. unscored questions to what happens when you fail and need to retake.

Frequently Asked Questions