Website accessibility starts with a real task
Finding a document, completing a form and receiving a response. Accessibility needs to work throughout the journey, across different ways of using the site.
Choose the journeys your site must support
For a portal, this might mean finding a contract, booking an appointment or submitting a report. For a business website, it might mean understanding a service and getting in touch. Such a journey combines navigation, content and interaction. Checking one opening screen does not tell you whether a visitor can complete the task.
Before design, identify the main journeys and content types users will encounter. Decide who will assess templates, forms and documents. If an external supplier provides a part of the journey, include it in the assessment plan and responsibilities.
Content needs a clear structure
Headings should describe their content and form a readable hierarchy. A link should explain its destination in context. In a table, users need to recognise the relationship between a heading and a value; for an image, they need its meaning. Include these decisions in editorial guidelines too.
Walk through the journey to a document, for example. Can a visitor identify the right file from its name? Can they find an explanation of its purpose? Is the document usable? A well-designed page can still fail at an attachment uploaded without review.
Try using the site without a mouse
Navigate the menu, search and form using a keyboard. Users must be able to see which element has focus, and the order should follow the meaning of the page. An open dialog must allow them to continue or close it. Check the way back when someone decides to stop the task too.
For the visual design, check contrast and zoom. Visitors may need larger text or a narrow viewport. Enlarged content must not hide an important action. Test real text and error messages, not just short sample labels.
Form errors should help people continue
When information is missing or has the wrong format, a form should identify the specific problem and where to correct it. Preserving the information already entered saves users more work. Check submission, waiting states and connection failures too.
State changes also need to reach people who cannot see them. When testing with a screen reader, check that fields are named and users receive information about the result. A button responding to a mouse click is not sufficient evidence.
Example test: submitting a resident's report
Choose a journey from the homepage to confirmation of submission. Follow it with a keyboard, at increased zoom and with a screen reader according to the assessment plan. Enter an invalid email and try an attachment the form will not accept. Check whether the user understands the cause and can continue without repeating the whole task.
After a successful submission, users need clear information about the result and the next step. This illustrative test covers more than the visual design of the form. It also provides a concrete procedure that can be repeated after changes to its fields or submission method.
Combine automated checks with manual tests
Automated tools help identify repeatable problems but cannot confirm full accessibility on their own. Supplement their results with manual assessment and tests of relevant journeys. WCAG 2.2 at level AA can serve as a reference framework; document the assessment scope and conclusion precisely.
Continue checking after launch whenever a template changes, a form is added or content is substantially updated. Editors need to know how to create headings, text alternatives and clear links. Accessibility remains part of working on a website after the first version has been handed over.
Put the topic into practice.
Related project: Bratislava – Staré Mesto