ARIA basics interview questions — Web Platform accessibility practice

aria-hidden controls only whether an element is exposed to assistive technologies; it does not change the visual appearance of the page. Content can remain fully visible to sighted users while being hidden from screen readers, and the reverse holds for CSS-based hiding. To visually hide something you need CSS properties like display: none or visibility: hidden, so the statement is false.

WCAG technique H67 specifies that decorative images should have an empty alt attribute so that assistive technology knows to skip them. Omitting the alt attribute entirely can cause some screen readers to fall back to announcing the image's file name or src URL, which is noise rather than information. An empty alt="" is the correct signal that the image is decorative.

The <label> element, when its for attribute matches a form control's id, programmatically associates the label text with that control. This gives the control an accessible name that screen readers announce and also enlarges the clickable hit area, improving both accessibility and usability. <fieldset> groups related controls, <legend> captions a <fieldset>, and <caption> titles a <table>, so none of these name an individual input.

ARIA stands for 'Accessible Rich Internet Applications.' It is a set of attributes (roles, states, and properties) defined by the W3C that supplement native HTML to make dynamic content and custom widgets accessible to assistive technologies. The missing word is 'Accessible.'

The role value main designates the primary content region of a page, the area where the distinctive content lives. Screen-reader users can jump straight to this landmark to bypass navigation and other peripheral content.

The first rule of ARIA is: if you can use a native HTML element or attribute that already provides the needed semantics and behavior, use that instead of ARIA. Native elements come with keyboard support, focus management, and role built in, so layering ARIA on top of them is redundant and error-prone.

The first rule of ARIA says that if a native HTML element or attribute already has the built-in semantics and behavior you need, you should use it instead of adding ARIA. ARIA is a supplement for cases with no native equivalent, such as custom widgets. The statement about using ARIA only when no native element or attribute provides the needed semantics or behavior is the one that matches this rule. Adding roles to every element does not follow the rule, ARIA does not control styling, and an ARIA role on a div does not add keyboard behavior, so a native button remains the correct choice.

A <div> is not in the default tab order and exposes no role, so assistive technology users who rely on keyboard navigation or screen readers cannot reach or identify it as a control. To make it accessible you would need role=button, tabindex=0, and keyboard event handlers (e.g. keydown for Enter/Space) — or, preferably, just use a native <button> element, which provides all of these by default.

The combination that works is the button role plus tabindex 0 plus a keyboard handler for Enter and Space that runs the same action as a click. The button role tells assistive technology to announce the element as a button; tabindex 0 places it in the sequential tab order so keyboard users can focus it; and the Enter/Space handler replicates the activation a native button gets for free. The alternatives fail for specific reasons: a link role misannounces the element, tabindex -1 removes it from the tab order, aria-hidden hides it from assistive technology entirely, and the presentation role strips its semantics while a click-only handler gives no keyboard access.

A tabindex of 0 places the element at its DOM position in the sequential Tab-key order, which is how a non-native element such as a <div> joins the natural tab order. A tabindex of -1 removes the element from sequential keyboard navigation but keeps it focusable by script via .focus(), which is useful for skip-link targets and dynamically managed focus.

This is false. ARIA roles only change the semantics exposed to assistive technologies; they add no behavior. A <div> with role="button" is still not focusable by default and does not respond to keyboard events. To make it keyboard-accessible, a developer must add tabindex="0" for focus and JavaScript handlers for Enter and Space. A native <button> provides all of this without extra code.

aria-hidden="true" removes the element and all of its descendants from the accessibility tree, so screen readers and other assistive technologies do not announce them. It has no effect on visual rendering or on the element's behavior; it only changes what assistive technologies perceive. Because it does not stop keyboard focus, applying it to a focusable element is an anti-pattern: a keyboard user can still tab to an element that screen readers no longer announce.

The aria-live attribute controls how screen readers announce dynamic content changes. polite means the assistive technology may announce updates but should not interrupt the user; it waits until the user is idle. assertive means the assistive technology should announce updates immediately, potentially interrupting the user's current interaction.

aria-hidden="true" removes the element from the accessibility tree, so screen readers skip the icon entirely while it stays visible to sighted users, and the visible text "Search" is still announced normally. Giving the SVG an aria-label adds an accessible name, which makes the icon more prominent to screen readers rather than hiding it. Setting aria-hidden="false" explicitly keeps the element exposed, and pointing aria-describedby at the label only attaches a description to the icon, so the icon is still read.

The first rule of ARIA is to use native semantics where possible; aria-label supplies an accessible name; aria-hidden="true" hides a node from assistive tech. ARIA only changes semantics — it adds no behavior, so keyboard handling (focus, Enter/Space, arrow keys) must still be implemented in JavaScript.

When alt is omitted entirely, the image has no explicit text alternative, so it does not get the decorative signal that alt='' provides. Many screen readers then fall back to the src value (the file name or URL) as a last-resort name, which is why that announcement may occur. The option stating that the browser assigns role="presentation" is wrong because browsers do not do that for images missing alt. The option claiming the image is not rendered is wrong because a missing alt has no effect on rendering. The option claiming the image is skipped just as with an empty alt is wrong because an empty alt is the explicit decorative signal, and omitting the attribute is not equivalent to it.

A native <button> fires a click event when the user presses Enter or Space, but a <div> does not. This code gives the div role='button' and tabindex='0', so it gets focus, yet its only activation path is the click listener. Keyboard users who press Enter or Space therefore never run the toggle logic. The fix is a keydown handler that calls the same toggle function for Enter and Space. The aria-pressed attribute is valid on the button role, tabindex='0' correctly makes the element focusable, and a div can receive click events from mouse and touch input, so the missing keyboard handling is the bug.

A native <button> converts Enter and Space key presses into a click event automatically, but a <div> with role="button" does not. In the given code the element is focusable (tabindex="0") and carries the correct ARIA attributes, so the sole defect is that no keyboard listener exists. Only the click handler is registered, so keyboard users can reach the control but cannot operate it. Adding a keydown (or keyup) handler that responds to Enter and Space and toggles the state fixes the behaviour.

The element is focusable because tabindex='0' places it in the tab order, and the keydown listener explicitly calls the click handler on Enter and Space, so keyboard activation works. The role='button' attribute only changes how the element is exposed to assistive technology; it does not add any keyboard or click behavior by itself, so the explicit keydown code is what makes keyboard use possible. The real defect is that the click handler only toggles a visual CSS class and never sets aria-pressed to 'true' or 'false'. Screen readers rely on that attribute to announce a toggle button's on or off state, so the state change is never communicated. The fix is to update aria-pressed inside the handler to mirror the visual state.

aria-live="assertive" tells assistive technology to announce updates to the region as soon as they occur, interrupting any speech in progress. That is the behaviour needed for critical error messages. aria-live="polite" queues the announcement until the user is idle, which is the cause of the delays. aria-live="off" disables announcements entirely, so it would make the problem worse. text is not a valid aria-live value; it is a role, not a live-region politeness setting.

The accname 1.2 algorithm gives aria-labelledby the highest precedence among name sources: when it references existing elements, their text alternatives are concatenated and used as the name, and the computation returns immediately. The referenced span's text is 'Cancel', so that is the accessible name. The aria-label value 'Save' and the button's text content 'Submit' are never consulted because the algorithm short-circuits at the aria-labelledby step.

Per the ACCNAME algorithm, the accessible name is decided in priority order. Step 2B (aria-labelledby) runs before step 2C (aria-label) and before the element's own text content (step 2F), so the button's name comes from the referenced element. The span with id lbl is named by computing its text alternative from its content, which includes the text node "Save " and the strong element's text "changes", yielding "Save changes". The button's text "Submit" and its aria-label "Cancel" are overridden and do not contribute to the name.

In the W3C Accessible Name and Description Computation, aria-labelledby has the highest precedence. When it yields a non-empty name, the algorithm returns immediately and neither aria-label nor the element's own text content is considered. Multiple aria-labelledby IDs are concatenated in listed order, giving 'Purchase completed'. Critically, aria-hidden on lbl1 does not block its text from being used: the spec explicitly provides that elements in the aria-labelledby or aria-describedby chain are still traversed for name computation even when hidden. aria-hidden controls whether an element is exposed in the accessibility tree on its own, not whether it can contribute to another element's name via a label reference. The text-content answer (Buy now) is wrong because text content is only consulted when neither aria-labelledby nor aria-label produces a name. The aria-label answer (Submit form) is wrong because aria-label is outranked by aria-labelledby. The concatenation answer (Buy now Purchase completed) is wrong because aria-labelledby replaces, not supplements, the text content when it resolves.

The AccName algorithm checks aria-labelledby (step 2B) before native host-language labeling and before name-from-content (step 2F), so the button's own text 'Click Me' is never used. When aria-labelledby holds several IDREFs, the algorithm computes the text alternative of each referenced element and concatenates them with spaces in the order the IDREFs appear in the attribute value, not in DOM order. Because the attribute lists lbl2 before lbl1, the result is 'Cannot Submit'.

aria-hidden='true' is a pure accessibility-tree mechanism: it removes the element and all descendants from the accessibility tree that assistive technology reads, but it does not alter DOM structure, CSS, or focusability. A native button or link inside the hidden subtree therefore stays in the sequential focus order, so a keyboard user can tab onto a control that screen readers never expose. The correct fix is to take those descendants out of the tab sequence (tabindex='-1' on each, or inert on the container) or not to hide interactive content with aria-hidden. The reference answer names both the spec behaviour (hiding from the accessibility tree only) and the resulting focus mismatch, which is what the question asks for.