Accessibility is primarily about people being able to complete the task they came to do.

On a website, that means finding information, using menus, understanding content and submitting forms without unnecessary obstacles. Additional display choices can help, but cannot replace an accessible core solution.

Navigation needs to work without a mouse

WCAG 2.1.1 requires functionality to be operable through a keyboard, with a limited exception for actions depending on a specific movement path.

This includes menus, links, buttons and forms.

WCAG 2.4.7 also requires visible keyboard focus. Users need to see which element is active before using it. A useful check therefore follows an entire key task rather than only the first button.

Readability is more than font size

WCAG 1.4.3 generally requires at least 4.5:1 contrast for normal text and 3:1 for large text, with defined exceptions.

Assess contrast in the situations where colours are actually used: ordinary text, links, buttons, focus indicators and different states.

WCAG 1.4.10 also requires content to reflow at narrow widths without losing information or functionality, except for content needing two-dimensional presentation.

A page can look organised on a large screen while developing serious problems when text is enlarged or the viewport narrows.

Personal display choices are a supplement

Northline is a self-initiated concept in which I explored personal choices for text size, contrast, spacing and reduced motion.

It also includes work on keyboard navigation, visible focus and page structure.

These settings can give users more control over presentation. They do not independently establish WCAG conformance. Northline is a learning and demonstration project, not an independent accessibility audit.

Automated tests do not find everything

W3C emphasises that automated tools alone cannot determine whether a website is accessible.

Combine technical tests with specific tasks: navigate by keyboard, open and close the menu, complete a form, trigger an error and check how it is explained.

Use a screen reader where relevant and involve people with disabilities when possible.

Prioritise obstacles that stop the task

An accessibility review is most useful when it produces specific findings.

It should identify actual obstacles, their severity, the tasks they affect and what needs correcting first. After changes, test the solution again.

Accessibility is therefore less a separate layer and more a quality standard for building the entire website.