Run a mock round

Both give an element an accessible name, but they work differently. aria-label sets the name directly to a string, for example a button with aria-label="Close dialog". aria-labelledby references the id of one or more elements whose text becomes the name, and multiple ids are concatenated in order.

<span id="billing">Billing address</span>
<input aria-labelledby="billing" />

Precedence matters: aria-labelledby wins over aria-label, which wins over native labelling such as label for, which wins over the element's own text content.

Use aria-labelledby when a visible label already exists, because it keeps the accessible name in sync with what sighted users see. Use aria-label when there is no visible text, and prefer a visually hidden native label for form fields over either. Do not put interactive content or long text in a label, and remember that aria-label is ignored on elements without a role that supports naming, such as a plain div.

Automated tools catch roughly a third of issues, so a complete audit combines them with manual and assistive-technology testing. Static checks include axe DevTools, Lighthouse, WAVE and lint plugins such as eslint-plugin-jsx-a11y or eslint-plugin-vuejs-accessibility in CI. These find missing alt text, contrast failures, missing labels and invalid ARIA.

Manual checks cover what tools cannot judge: meaningful reading order, sensible heading structure, keyboard-only operation of every flow, visible and logical focus, clear error identification and suggestions, and whether alt text actually describes the image's purpose.

Test with real assistive technology: NVDA or JAWS on Windows, VoiceOver on macOS and iOS, TalkBack on Android. Navigate by headings, landmarks, links and form fields, and try completing core tasks with the screen reader on. Include users with disabilities where possible.

Document conformance against WCAG 2.2 AA, track issues, and add regression tests so fixes do not break. Accessibility is a continuous practice, not a one-time audit.

When no native element supports the interaction, you implement an ARIA design pattern and must replicate all the expected behaviour. A custom combobox, for example, needs role="combobox", aria-expanded, aria-controls and aria-activedescendant, plus a popup with role="listbox" containing role="option" children with aria-selected. Keyboard support is part of the contract: arrow keys move the active option, Enter selects, Escape closes and returns focus, and typing filters. Managing aria-activedescendant is often easier than moving DOM focus, but the active id must stay in sync.

Common failures include using role="button" without Space and Enter handling or keyboard focus, missing or stale aria-expanded on disclosure widgets, focus traps that cannot be escaped, and redundant ARIA that conflicts with native semantics.

Follow the WAI-ARIA Authoring Practices examples closely, prefer a tested headless library such as Radix, Headless UI or React Aria over hand-rolling, and verify with keyboard-only use and a screen reader.

Semantic HTML uses elements that describe meaning: header, nav, main, section, article, aside, footer, button, label, table and ul. Assistive technologies and browsers derive roles, names, states and keyboard behaviour from these elements for free. A button announces itself as a button, is focusable and responds to Enter and Space. A styled div with an onclick does none of that without extra code, and the extra code is easy to get wrong.

Headings h1 to h6 form an outline that screen reader users navigate by, so use them for structure, not for font size. Landmarks let users jump between regions. Lists group related items, and tables with th and scope expose relationships.

Semantic markup is also better for SEO, easier to style and more robust than ARIA. The first rule of ARIA is not to use ARIA when a native element already does the job. Incorrect ARIA is often worse than none, because it overrides correct native semantics.

Every interactive element must be reachable and operable with the keyboard alone. Native elements such as button, a[href], input, select and textarea are focusable and handle Enter and Space automatically. A clickable div is not, and adding tabindex="0" plus key handlers is usually a sign to use a button instead. Use tabindex="0" sparingly to add elements to the tab order and tabindex="-1" to make something programmatically focusable without adding it to the sequence.

Focus must be visible, so never remove outlines without a clear replacement, such as :focus-visible styles. Tab order should follow the visual and logical reading order, and positive tabindex values should be avoided because they create a confusing parallel order.

Manage focus when content changes: move focus into a dialog and trap it there, return it to the trigger on close, and after deleting an item move focus to a sensible neighbour. Add a skip link to bypass repeated navigation, and test by unplugging the mouse.

WCAG is organised around four principles known as POUR. Perceivable means information must be available to the senses, for example text alternatives for images, captions for video, sufficient colour contrast and content that works when zoomed. Operable means the interface must work without a mouse, with full keyboard access, visible focus, enough time to complete tasks, no content flashing more than three times per second, and touch targets large enough. Understandable means text should be readable, the interface should behave predictably, and users should get help avoiding and correcting errors. Robust means content should work with current and future assistive technologies, which in practice means valid semantic markup and correct ARIA.

Each principle has testable success criteria at three levels: A as the minimum, AA as the common legal target, and AAA as enhanced. Most accessibility laws reference WCAG 2.1 or 2.2 AA.

WCAG contrast is measured as a ratio between the relative luminance of text and its background, ranging from 1:1 to 21:1. At level AA, normal text needs at least 4.5:1 and large text, meaning 18pt or 24px, or 14pt bold, needs 3:1. At AAA the thresholds are 7:1 and 4.5:1. Non-text content such as form borders, meaningful icons and focus indicators needs 3:1 against adjacent colours under the non-text contrast criterion.

Important nuances: colour alone must never convey information, so pair colour with text, an icon or a pattern. Links inside body text need to be distinguishable by more than colour. Ratios apply to solid backgrounds; text over images needs a scrim or solid backing.

Check with browser DevTools' contrast checker or tools like axe and the Colour Contrast Analyser, and test both light and dark themes. A passing ratio does not guarantee readability for people with low vision, but it is the enforceable baseline.