Accessible HTML: Interview Questions and Answers

Accessibility starts with the elements and relationships already available in HTML. These questions are best answered with examples and an explanation of what a keyboard or screen-reader user needs.

1. What is the first step toward accessible HTML?#

Use native HTML elements for their intended purpose. A real button already supports keyboard activation and exposes button semantics. A real label is associated with its form field. Native elements reduce the amount of custom JavaScript and ARIA needed. Start with semantic markup, then test the result.

2. What is an accessible name?#

An accessible name is the label exposed to assistive technology for a control or other named element. It can come from visible text, a connected label, aria-label, or aria-labelledby, depending on the element. Prefer visible, programmatically associated text when possible because it helps everyone, not just screen-reader users.

3. When should you use ARIA?#

Use ARIA when native HTML cannot express a needed role, state, or relationship. It does not add keyboard behavior by itself and cannot turn a generic element into a fully working control. The first choice should be a native element; add ARIA only when a specific accessibility gap remains and test it with assistive technology.

4. What is the difference between aria-label and aria-labelledby?#

aria-label supplies a string directly as the accessible name. aria-labelledby points to one or more elements whose text becomes the name. If a visible heading or label already exists, referencing it with aria-labelledby avoids maintaining duplicate text. Do not add ARIA names that conflict with visible labels.

5. How should form errors be presented?#

Explain what went wrong in text, identify the affected field, and describe how to fix it. Connect the message to the control with aria-describedby when appropriate, and expose invalid state with aria-invalid="true" after validation. On submission, provide a useful error summary and move focus thoughtfully when the user needs to find errors. Color alone is not enough.

6. Why is keyboard testing important?#

Some users do not use a mouse. Keyboard testing checks whether links and controls can be reached, whether focus order is understandable, whether focus is visible, and whether interactive controls can be operated. Use Tab, Shift+Tab, Enter, Space, and arrow keys where appropriate. Native controls usually provide expected keyboard behavior automatically.

7. What is the purpose of the alt attribute for screen-reader users?#

It communicates the relevant information or function of an image when the image itself cannot be perceived. The right wording depends on context. A chart needs its important takeaway or a nearby data explanation; a decorative flourish should be skipped with alt="". Avoid repeating the caption word for word unless it adds useful information.

8. Why should the page declare its language?#

A language declaration helps assistive technology pronounce words using the right language rules. It also supports translation and other language-aware processing. Put the primary language on the html element, for example lang="en", and mark a passage in another language on the element containing that passage.

9. What is the difference between a visible label and a placeholder?#

A visible label remains available when a user enters a value and gives the field a stable name. Placeholder text is a short hint inside an empty control; it can disappear and often has lower contrast. Use both when useful, but do not use a placeholder as the only label.

10. How do you check whether HTML is accessible?#

Start with a keyboard-only pass, inspect headings and landmarks, check labels and accessible names, verify image alternatives, and review contrast and focus styles. Run an automated accessibility checker to find some common issues, then test important flows with screen readers and real users where possible. Automated tools cannot judge every usability problem.