Web Platform accessibility interview questions

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 aria-label attribute supplies an accessible name directly on the element. Without visible text content, the button would otherwise be announced generically, with no indication of what it does. The alt attribute is not valid on a button element, so it does not provide a name. aria-hidden="true" removes the control from the accessibility tree entirely, and role="presentation" strips the button role, so neither gives the control a name.

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.

The keyed answer is aria-live="assertive". An ARIA live region announces content changes to assistive technology, and the aria-live value sets the priority: assertive announces the change immediately and interrupts current speech. The polite value queues the announcement until the screen reader is idle, so it does not meet the requirement of interrupting. aria-busy="true" signals that a region is being updated and asks assistive technology to wait, which is the opposite of an immediate announcement. aria-hidden="true" removes content from the accessibility tree entirely, so the error would never be read. The error container should already exist in the DOM when the message text changes, since live regions are most reliably announced when their content is updated rather than when the region itself is inserted.

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-hidden is a semantic signal only: per the WAI-ARIA spec it removes the element and its subtree from the accessibility tree, but it does not alter focus or tab order. An anchor with an href is focusable by default in HTML, so it stays reachable by keyboard while being invisible to assistive technology. The remedy is either to drop aria-hidden (keeping the control perceivable, e.g. with visually-hidden styling) or to also remove it from the tab sequence with tabindex="-1" for one element or the inert attribute for a subtree.

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.

aria-hidden removes an element and its descendants from the accessibility tree but has no effect on keyboard focus. A native anchor with an href remains focusable, so keyboard users can land on a control that screen readers cannot name or announce, which violates WCAG 2.1 SC 4.1.2. The correct fix is to remove aria-hidden from any ancestor of focusable content, or to take the hidden overlay out of both the accessibility tree and the tab order (for example with the hidden attribute, inert, or DOM removal). tabindex='-1' only prevents Tab focus and leaves the mismatch in place for other focus routes, so it is not the primary fix.

The button has the default role button, and aria-pressed="true" is mapped by the Core Accessibility API Mappings to the pressed state with value true, so the button is exposed as a toggle button in the pressed position. The aria-pressed attribute has no default value; when it is absent, the button is not a toggle button and no pressed state is exposed in the accessibility tree. This is different from aria-pressed="false", which still exposes a toggle button in the unpressed position.