Jan Mikoláš
Glossary
Web accessibility
An accessible website is not a special variant for a small group of people. It is an interface whose content and controls make sense without a mouse, with enlarged text, with assistive technology, or under nonstandard conditions.
Short definition
A usable website communicates meaning and state in more than one way.
Accessibility is not only technical validity or colour contrast. It begins with semantic HTML: a real link navigates, a button performs an action, headings describe the hierarchy, and a label names a form field. This lets browsers and assistive technologies understand the content without developers having to describe everything again manually.
Operability matters too. Users must be able to reach features with a keyboard, see focus, understand a form error, and discover that content changed after an asynchronous action. WCAG summarises four useful principles: content should be perceivable, operable, understandable, and robust. The specific solution must still be verified in the given interface.
The problem it solves
It removes barriers encountered during ordinary use of the web.
People differ in their vision, hearing, mobility, language, and technology. Accessibility also supports users with temporary limitations, slow connections, or small screens.
- navigating, searching, and reading content with a keyboard or screen reader
- checkout, sign-in, and administration forms with clear labels and errors
- dynamic components such as dialogs, autocomplete fields, filters, and notifications
- content usable with enlarged text, high contrast, or reduced motion
- e-commerce and internal systems where completing an action correctly matters, not merely displaying a page
Practical example
A native button and announced status instead of simulated controls
A native button can automatically be operated with Tab, Enter, and Space. Once results load successfully, an information region with role=status announces the update to a screen reader; the text itself is set through textContent rather than by inserting untrusted HTML. A dialog would additionally require managing focus and restoring it.
Here, ARIA supplements information about a changing state. It does not replace the button with role="button" on a div. Where a suitable native element exists, its actual behaviour, semantics, and compatibility should be preferred.
HTML and JavaScript
<button type="button" id="load-orders">Načíst objednávky</button>
<p id="orders-status" role="status" aria-live="polite"></p>
<script>
document.querySelector('#load-orders').addEventListener('click', () => {
document.querySelector('#orders-status').textContent = 'Objednávky byly načteny.';
});
</script>How it works
The user journey: structure → controls → feedback
This simple flow is a text alternative to a diagram of an accessible interface. Every step must work without relying on appearance alone.
- Content has structure HTML identifies the main content, navigation, headings, links, and form elements. A screen reader can then offer navigation by landmarks and headings.
- The user can reach the controls The Tab key moves through elements in a logical order. The active element has a visible focus indicator and the action can be performed without precise mouse movement.
- The interface communicates state Errors, loading, success, and content changes are not conveyed only through colour or animation. They need clear text and sometimes an appropriate announcement.
- A dynamic section preserves context After SPA navigation, the page title and main heading are updated, as is focus where needed. When a dialog closes, focus returns to the element that opened it.
- The scenario is tested An automated audit catches some technical errors. Manual testing with Tab and zoom, and ideally with users verifies whether the whole experience genuinely makes sense.
Important related concepts
Semantics, focus, and status information are fundamental building blocks.
Individual measures complement each other. Contrast without keyboard support and ARIA without meaningful behaviour do not create a usable component.
Semantic HTML
Native nav, main, h1, a, button, form, label, and input elements convey roles and expected behaviour. Before creating a custom widget, always ask whether a suitable HTML element can provide it.
Keyboard and focus
Focus shows where the user is. It must not be removed without an equivalent or better replacement. When a modal opens, after navigation, or when an error appears, the destination of focus must be determined.
Screen reader
A screen reader works with semantics and the accessibility tree, not merely visual appearance. Meaningful names, headings, labels, and textual errors therefore matter more than decorative ARIA.
Contrast and multiple channels
Colour must not be the only carrier of an error, state, or instruction. Text, an icon with a description, and suitable contrast help different users and people using a low-quality display.
WCAG and testing
WCAG provides testable criteria and the principles of perceivability, operability, understandability, and robustness. Automation is useful, but cannot determine whether a label makes sense in context, for example.
Benefits and limitations
Accessibility broadens interface quality but requires continuous attention.
Benefits
- more people can complete the same task without special support
- semantic structure improves maintenance, testability, and often navigation through content
- keyboard focus, textual errors, and clear states also help experienced users
- continuous testing detects regressions earlier than a one-off check before release
Risks and common mistakes
- removing the focus outline without a functional replacement
- a clickable div, a link without an href, or a custom widget without keyboard behaviour
- information conveyed only through colour, an icon, or a rapid animation
- a modal without focus movement and return, or dynamic content without an announcement
- relying on an automated audit as proof of complete accessibility
Practical use
An accessible form dialog needs more than attractive styling.
Consider a modal for editing a delivery address. A real button opens it, the dialog has a visible name, and it receives focus when opened. While open, keyboard navigation stays within the relevant content; Escape can close it and focus returns to the original button. The form inside uses labels and, after an invalid submission, communicates an error through text associated with the relevant field.
This behaviour cannot be verified merely by looking at a screenshot. Keyboard navigation through the dialog must be tested, along with use of a screen reader, and checked to ensure the user does not become lost after an error. If an SPA performs the same action without a reload, the application also has a responsibility to announce the change and preserve orientation after client-side navigation.
What to consider
Accessibility belongs in the definition of done.
Regular small checks while creating components cost less than repairing the entire application after completion.
- start with native HTML and add ARIA only when native semantics are insufficient
- verify complete keyboard operation, visible focus, Escape, and focus return for dialogs
- associate form fields with labels, guidance, and errors; do not convey information through colour alone
- test zoom, responsive layouts, reduced motion, and dynamic content updates
- combine automated checks with manual testing and, where possible, with people who use assistive technologies
Common questions
Web accessibility in practice
Is valid HTML enough?
No. Validity helps reveal some errors but does not guarantee a logical hierarchy, labels, sufficient contrast, a keyboard path, or comprehensible feedback after an action.
Should I use ARIA for everything?
No. Where a suitable native HTML element exists, it generally provides better behaviour and semantics. ARIA should supplement specific information or a custom widget whose behaviour you also implement fully.
Is an automated audit sufficient?
No. It is excellent for repeatable technical checks but cannot identify every problem with context, order, textual meaning, or the actual operability of a complex flow.
Does accessibility concern only blind users?
No. It also helps people with limited mobility, hearing or cognitive impairments, temporary injuries, small displays, enlarged text, or unusual input devices.
How I create web interfaces in practice
I evaluate usability across the whole journey, not only in an individual component.
When developing web applications, I address semantics, forms, dynamic states, and layout so that the interface remains comprehensible with both standard and alternative interaction methods.