🏷️ ARIA Language
Master vocabulary for ARIA roles, states, properties, and landmark navigation. Intermediate
The component uses role="dialog" and aria-modal="true".
What does the ARIA role attribute communicate?
ARIA role communicates element semantics to assistive technologies. role="dialog" signals a modal dialog to screen readers:
| ARIA role type | Examples |
|---|---|
| Landmark roles | banner, navigation, main, complementary, contentinfo |
| Widget roles | dialog, button, tab, tabpanel, listbox, combobox |
| Document structure roles | article, list, heading, img, presentation |
First rule of ARIA: don't use ARIA if native HTML provides the same semantics — use <button> not <div role="button">. Key vocabulary: "landmark role", "widget role", "aria-modal", "focus trapping in dialogs".
The loading spinner uses aria-live="polite".
What does an aria-live region do?
aria-live regions enable screen readers to announce dynamic content updates without requiring the user to navigate to the changed element:
| Value | Behaviour | Use case |
|---|---|---|
polite | Announce after current speech completes | Status messages, loading indicators |
assertive | Interrupt current speech immediately | Critical errors, time-sensitive alerts |
off | No announcement | Default; use when updates are not important |
Key vocabulary: "live region", "dynamic content", "polite vs. assertive", "atomic update", "aria-relevant".
The design uses ARIA landmarks to structure the page.
What are ARIA landmark roles used for?
ARIA landmarks map HTML5 sectioning elements to navigable regions for screen reader users:
| HTML element | Landmark role | Screen reader shortcut |
|---|---|---|
<header> | banner | NVDA: D, JAWS: R |
<nav> | navigation | NVDA: D, JAWS: R |
<main> | main | NVDA: D, JAWS: R |
<aside> | complementary | NVDA: D, JAWS: R |
<footer> | contentinfo | NVDA: D, JAWS: R |
Key vocabulary: "landmark navigation", "skip navigation", "document structure", "landmark bypass".
The button state is communicated via aria-expanded="false".
What type of ARIA attribute is aria-expanded and what does it communicate?
ARIA distinguishes between states (dynamic, change frequently) and properties (relatively static):
| Type | Examples | Changes? |
|---|---|---|
| ARIA states | aria-expanded, aria-checked, aria-selected, aria-pressed | Yes — via JavaScript |
| ARIA properties | aria-label, aria-labelledby, aria-describedby, aria-controls | Rarely |
aria-expanded="false" tells screen readers the controlled element (panel, menu) is collapsed. Update it to "true" when opened. Key vocabulary: "ARIA state", "controlled element", "aria-controls", "toggle state announcement".
The input has aria-describedby="hint-text error-text".
What does aria-describedby provide?
ARIA provides three distinct ways to supply names and descriptions to form fields:
| Attribute | Purpose | Screen reader announcement |
|---|---|---|
aria-label | Provides the accessible name directly as a string | As primary label |
aria-labelledby | References element(s) that provide the accessible name | As primary label |
aria-describedby | References element(s) with supplementary description | After label and role |
Key vocabulary: "label vs. description", "error association", "form field description chain", "duplicate description prevention".
Sarah: 'Hey team, I'm using aria-label on this button to provide a tooltip. It's working great, but I'm not sure if it's the *best* approach. Should I be considering other ARIA attributes like aria-labelledby? I want to ensure screen reader users fully understand what the button does without needing to hover over it or read the surrounding text.aria-label provides a text alternative for the button. However, it's often less flexible than aria-labelledby, which allows you to explicitly link the label to another element on the page (like a descriptive tooltip). Using aria-labelledby gives screen reader users more precise control over how they navigate and understand the button's purpose; simply stating the action isn't always enough context.Reviewer: 'I noticed you've used `aria-describedby` on this form field. It seems a little redundant – we already have clear labels and instructions for the user. Are you sure you're not overusing ARIA here, potentially adding unnecessary complexity for screen readers?'<button aria-expanded="false">Click Me</button>
During a code review, David asks: 'I'm using aria-expanded on this button to indicate whether it's currently active. Is this the correct way to communicate its state to screen readers?'Which of the following best describes the purpose and implications of using
aria-expanded in this scenario?aria-expanded attribute communicates the *current* state of an interactive element to assistive technologies. However, it's crucial to understand that it primarily focuses on whether the action is enabled or disabled, not necessarily a visual representation for sighted users. Options A and D incorrectly suggest alternative approaches or misinterpret its primary function. Option B is partially correct but misses the core purpose – screen readers *do* rely on this attribute to manage state.data attribute. Do you think it's appropriate to continue using `aria-describedby`, or should I explore alternative ARIA techniques to ensure screen reader users receive the most efficient and accessible information?'. Which of the following best describes Alex's concern and the correct approach?aria-describedby can be useful, it's crucial to avoid overwhelming screen reader users with extraneous information. The primary goal is efficient access – the label and data attribute should usually suffice. Using aria-describedby only when truly necessary provides a more streamlined experience for assistive technology users.aria-controls on this modal. It seems like a good way to link the button and the modal content for screen reader users. However, I'm also using aria-expanded on the button itself. Are these attributes working together effectively to provide a seamless experience for accessibility, or could we be creating confusion?'aria-controls and aria-expanded. `aria-controls` specifies the content that the element controls (the modal), while `aria-expanded` indicates whether that content is currently visible. Using both together provides a clear signal to screen readers about the state of the interaction, enhancing usability. The other options misinterpret the roles or suggest unnecessary duplication.Sarah: 'Hey team, I'm using aria-label on this button to provide a tooltip. It's working great, but I'm not sure if it's the *best* approach. Should I be considering other ARIA attributes like aria-labelledby? I want to ensure screen reader users fully understand what the button does without needing to hover over it or read the surrounding text.aria-label provides a text alternative for the button. However, it's often less flexible than aria-labelledby, which allows you to explicitly link the label to another element on the page (like a descriptive tooltip). Using aria-labelledby gives screen reader users more precise control over how they navigate and understand the button's purpose; simply stating the action isn't always enough context.Reviewer: 'I noticed you've used `aria-describedby` on this form field. It seems a little redundant – we already have clear labels and instructions for the user. Are you sure you're not overusing ARIA here, potentially adding unnecessary complexity for screen readers?'<button aria-expanded="false">Click Me</button>
During a code review, David asks: 'I'm using aria-expanded on this button to indicate whether it's currently active. Is this the correct way to communicate its state to screen readers?'Which of the following best describes the purpose and implications of using
aria-expanded in this scenario?aria-expanded attribute communicates the *current* state of an interactive element to assistive technologies. However, it's crucial to understand that it primarily focuses on whether the action is enabled or disabled, not necessarily a visual representation for sighted users. Options A and D incorrectly suggest alternative approaches or misinterpret its primary function. Option B is partially correct but misses the core purpose – screen readers *do* rely on this attribute to manage state.data attribute. Do you think it's appropriate to continue using `aria-describedby`, or should I explore alternative ARIA techniques to ensure screen reader users receive the most efficient and accessible information?'. Which of the following best describes Alex's concern and the correct approach?aria-describedby can be useful, it's crucial to avoid overwhelming screen reader users with extraneous information. The primary goal is efficient access – the label and data attribute should usually suffice. Using aria-describedby only when truly necessary provides a more streamlined experience for assistive technology users.aria-controls on this modal. It seems like a good way to link the button and the modal content for screen reader users. However, I'm also using aria-expanded on the button itself. Are these attributes working together effectively to provide a seamless experience for accessibility, or could we be creating confusion?'aria-controls and aria-expanded. `aria-controls` specifies the content that the element controls (the modal), while `aria-expanded` indicates whether that content is currently visible. Using both together provides a clear signal to screen readers about the state of the interaction, enhancing usability. The other options misinterpret the roles or suggest unnecessary duplication.Sarah: 'Hey team, I'm using aria-label on this button to provide a tooltip. It's working great, but I'm not sure if it's the *best* approach. Should I be considering other ARIA attributes like aria-labelledby? I want to ensure screen reader users fully understand what the button does without needing to hover over it or read the surrounding text.aria-label provides a text alternative for the button. However, it's often less flexible than aria-labelledby, which allows you to explicitly link the label to another element on the page (like a descriptive tooltip). Using aria-labelledby gives screen reader users more precise control over how they navigate and understand the button's purpose; simply stating the action isn't always enough context.Reviewer: 'I noticed you've used `aria-describedby` on this form field. It seems a little redundant – we already have clear labels and instructions for the user. Are you sure you're not overusing ARIA here, potentially adding unnecessary complexity for screen readers?'<button aria-expanded="false">Click Me</button>
During a code review, David asks: 'I'm using aria-expanded on this button to indicate whether it's currently active. Is this the correct way to communicate its state to screen readers?'Which of the following best describes the purpose and implications of using
aria-expanded in this scenario?aria-expanded attribute communicates the *current* state of an interactive element to assistive technologies. However, it's crucial to understand that it primarily focuses on whether the action is enabled or disabled, not necessarily a visual representation for sighted users. Options A and D incorrectly suggest alternative approaches or misinterpret its primary function. Option B is partially correct but misses the core purpose – screen readers *do* rely on this attribute to manage state.data attribute. Do you think it's appropriate to continue using `aria-describedby`, or should I explore alternative ARIA techniques to ensure screen reader users receive the most efficient and accessible information?'. Which of the following best describes Alex's concern and the correct approach?aria-describedby can be useful, it's crucial to avoid overwhelming screen reader users with extraneous information. The primary goal is efficient access – the label and data attribute should usually suffice. Using aria-describedby only when truly necessary provides a more streamlined experience for assistive technology users.aria-controls on this modal. It seems like a good way to link the button and the modal content for screen reader users. However, I'm also using aria-expanded on the button itself. Are these attributes working together effectively to provide a seamless experience for accessibility, or could we be creating confusion?'aria-controls and aria-expanded. `aria-controls` specifies the content that the element controls (the modal), while `aria-expanded` indicates whether that content is currently visible. Using both together provides a clear signal to screen readers about the state of the interaction, enhancing usability. The other options misinterpret the roles or suggest unnecessary duplication.Sarah: 'Hey team, I'm using aria-label on this button to provide a tooltip. It's working great, but I'm not sure if it's the *best* approach. Should I be considering other ARIA attributes like aria-labelledby? I want to ensure screen reader users fully understand what the button does without needing to hover over it or read the surrounding text.aria-label provides a text alternative for the button. However, it's often less flexible than aria-labelledby, which allows you to explicitly link the label to another element on the page (like a descriptive tooltip). Using aria-labelledby gives screen reader users more precise control over how they navigate and understand the button's purpose; simply stating the action isn't always enough context.Reviewer: 'I noticed you've used `aria-describedby` on this form field. It seems a little redundant – we already have clear labels and instructions for the user. Are you sure you're not overusing ARIA here, potentially adding unnecessary complexity for screen readers?'<button aria-expanded="false">Click Me</button>
During a code review, David asks: 'I'm using aria-expanded on this button to indicate whether it's currently active. Is this the correct way to communicate its state to screen readers?'Which of the following best describes the purpose and implications of using
aria-expanded in this scenario?aria-expanded attribute communicates the *current* state of an interactive element to assistive technologies. However, it's crucial to understand that it primarily focuses on whether the action is enabled or disabled, not necessarily a visual representation for sighted users. Options A and D incorrectly suggest alternative approaches or misinterpret its primary function. Option B is partially correct but misses the core purpose – screen readers *do* rely on this attribute to manage state.data attribute. Do you think it's appropriate to continue using `aria-describedby`, or should I explore alternative ARIA techniques to ensure screen reader users receive the most efficient and accessible information?'. Which of the following best describes Alex's concern and the correct approach?aria-describedby can be useful, it's crucial to avoid overwhelming screen reader users with extraneous information. The primary goal is efficient access – the label and data attribute should usually suffice. Using aria-describedby only when truly necessary provides a more streamlined experience for assistive technology users.aria-controls on this modal. It seems like a good way to link the button and the modal content for screen reader users. However, I'm also using aria-expanded on the button itself. Are these attributes working together effectively to provide a seamless experience for accessibility, or could we be creating confusion?'aria-controls and aria-expanded. `aria-controls` specifies the content that the element controls (the modal), while `aria-expanded` indicates whether that content is currently visible. Using both together provides a clear signal to screen readers about the state of the interaction, enhancing usability. The other options misinterpret the roles or suggest unnecessary duplication.Frequently Asked Questions
What will I practice in "ARIA Language | Accessibility Exercises"?
This is an Accessibility Language exercise set. It walks through 25 scenario-based multiple-choice questions built around real usage of Accessibility Language terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 25 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the Accessibility Language vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more Accessibility Language exercises?
See the Accessibility Language exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — Accessibility Language vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.