Web Accessibility: How to Decide What to Improve on Your Site

A person arrives at your service page, but fails to send the form: the keyboard does not reach the send button, an error notice is not understood, or the contrast makes it difficult to read the fields. Information is published, but the task is not completed.

Web accessibility is about reducing those barriers so that more people can perceive, understand and use a site. In this hypothetical practical case you will see how to move from a concrete incidence to a reasonable scope of improvement. At the end you will be able to decide what to review first, what to ask the developer of your website and how to check that a change works in real situations.

Scenario initial situation

Imagine a small service company that receives requests from its website. Its manager detects that some people leave the form and asks a broad request: "you have to make the website accessible".

This is valid, but it does not yet allow decisions to be made. A website brings together content, menus, images, forms and interactive elements. Each part can create a different barrier.

Before choosing tools or visual changes, it is important to specify what a person should be able to do on the web. In this example, the priority task would be:

Find a service, read your information, fill out a form and know if the request has been sent correctly.

The aim would not be to add an accessibility label to the site, but to facilitate that route without requiring the use of a device, capacity or unique form of navigation.

Observable problem: the route is broken

Several obstacles appear in the scenario review. It is not necessary that everyone be present in your site for the example to be useful:

• Menu links are distinguished only by colour and do not clearly show which focus is on keyboard navigation.
• The form fields show a phrase inside the box, but not a persistent label explaining what data is requested.
• If a mandatory field is missing, the error message appears far from the place where the problem occurred.
• A button contains only one icon and its function is unclear to those who do not see that icon or use support technology.
• The final message is briefly displayed and may go unnoticed.

The common denominator is not aesthetic, it is barriers that hinder concrete actions.

Here it is useful to separate two questions. The first is business: what route should a person be able to complete? The second is implementation: what content, interaction and behaviour must be adjusted to achieve this? Confused often leads to isolated arrangements that do not solve the whole task.

Objective analysis: make an important action usable

In the case, the company decides to prioritize the form because it is the main way to start a conversation. That objective can be expressed in a verifiable way:

A person must be able to submit a request, understand the required fields, correct an error and receive a clear confirmation.

This formulation helps to avoid decisions based only on appearance. For example, increasing the size of a text may be useful, but it will not solve a form that cannot be navigated with keyboard. Similarly, adding alternative text to an image does not replace a header structure that allows you to understand the page.

Web accessibility often requires a review of various modes of use: keyboard browsing, content reading, interaction with forms, text expansion and understanding of notices. The weight of each review depends on what your website does.

If the site offers reservations, purchase, private access or management tools, the analysis should include those tasks and their status: what happens before the start, during the process and when there is an error. Obligations applicable to your activity or type of service should be validated with the appropriate expert advice; a technical review does not replace that assessment.

Proposed scope: intervening where experience changes

With the objective defined, the scope of the hypothetical case would not be to "review everything" without further ado. It would concentrate on the priority route and the elements that support it:

Estructure of the service page. Check that titles sort the information and that links explain where they lead. 2.

Keyboard Navigation. Check that links, fields and buttons can be accessed in an understandable order, and that the focus is visually identified. The focus is the signal indicating which item will receive the next keyboard action. 3.

Form. Associate each field with a clear indication, point out the necessary data and explain the errors along with a way to correct them. 4.

Boots and icons. Ensure that the action is understood without relying solely on an image, colour or a screen position. 5.

SShipping confirmation. show a visible and understandable message that confirms the result or indicates what should be reviewed.

This scope does not presuppose a specific technology. It may require changes in content, design or code depending on how the site is built. It is also appropriate to leave out, expressly, areas that have not yet been reviewed. Thus, you avoid taking the whole of the website for granted when the intervention has focused only on a route.

Solution and Check: Test the task, not just components

In the scenario, the application starts by improving the page and form. A visible label is maintained in each field, a recognizable focus is defined, the buttons with icons are clarified and messages are reformulated to indicate what has failed and how to correct it.

The subsequent check is not limited to confirming that the changes are published. The initial task is repeated under different conditions:

• to browse the page and form using only the keyboard;
• extend the text to check whether the content remains legible and operable;
• cause an intentional error to check where the notice appears and if understood;
• send a correct request and confirm that the result is clear;
• review the contents and components added so that they do not reintroduce the same barrier.

These tests do not allow you to declare that a site will be suitable for all people and all contexts. If you convert a general intention into visible acceptance criteria. If a person cannot locate the field with error or does not know if the shipment has been completed, the task is still unresolved.

It is also important to maintain improvements. A new template, an external form, a design change or content load can modify previous behaviour. Therefore, accessibility should be part of the usual decisions of evolution of the web, not stay in an isolated correction.

Transferable learning for your website

The case leaves three ideas applicable to a SME or a standalone business:

• Start with an essential action for your activity: ask for information, book, buy, download a document or access a private area.
• It describes the expected outcome from the point of view of the visitor to the website. "Power to send a request and understand the answer" allows for a better decision than "improving accessibility".
• He asks that the solution include a way to check it. A change is better defined when you can test it on the route you intend to improve.

Web accessibility is not resolved with a single visual adjustment or generic formula. It is done by identifying barriers in important tasks, prioritizing those that prevent progress and verifying the result with real uses of the page.

If you are not clear which user journey to review first or what changes your site requires, you can explain your web development project to assess the technical scope of a review and proportionate improvement.