This website goes above and beyond the official guidelines for accessibility compliance (aka Web Content Accessibility Guidelines or WCAG), and meets their level AA requirements. These requirements and guidelines are written and upheld by the World Wide Web Consortium (aka W3C). For this website, I have tried to keep it short, use simple language, write simple sentences, add additional descriptive moderation for screen readers, and write meaningful headlines, body copy, links, buttons, etc., so that anyone who uses assistive technology, does not meet any hurdles on this website. Everyone, independent of their abilities, should be able to surf the web, book a cinema ticket, submit an online job application, buy in an online shop, book an online appointment, do their online banking etc.
Get in touch if you need help with your accessibility or to tell me about some issue my website has.

In the EU web accessibility to virtually every online service will be a legal requirement as of June 2025. The European Accessibility Act is an EU level directive. That means each country has their own interpretation and law. The intention is to, at the very least, match the requirements & guidelines set out in the WCAG. The German version is known as the Barrierefreiheits­stärkungs­gesetz (BFSG).

Web accessibility means that websites, like this one, are designed and developed so that people can use them, irrespective of any difficulties they those people have. Literally, any single step that you can make towards this goal is a good one, making the web useable for more people, can also mean new customers.

Making the web accessible means it works for all people, whatever their hardware, software, language, location, or ability, which benefits individuals, businesses, and society. Access by everyone regardless of disability is an essential aspect of the internet.

Disabled people bring the most obvious difficulties to the table, and face the greatest challenge using the web. Disabled, in the context of the web, could mean any of these or any combination of these: hearing difficulties (aka auditory challenges), difficulties in understanding things, words, sentences (aka cognitive challenges), limited body movements and dexterity (aka physical challenges), difficulties with speech, and most obviously, difficulties with vision (aka visually challenged).

A user doesn't need to be disabled in order to face challenges using the internet. The other, frequently forgotten, group of users without obvious disabilities could mean any of these or any combination of these: older people with changing abilities (aka ageing), people with a broken arm or lost glasses (aka temporarily disabled), people working in bright sunlight or in a very loud environment (aka situational limitations).

Photo by Georg Arthur Pflueger on Unsplash Photo by Prakriti Khajuria on Unsplash

To be clear about accessibility, the following 6 requirements are the absolute minimum that any website needs to consider. Many aspects of accessibility are fairly easy to understand and implement. This simple checklist of steps is a simple overview of the must-haves so that accessibility is addressed in the most basic way.

1 - Every page needs a page title

Each page needs its own unique title that start with the most specific information. Page titles help with orientation by letting people know where they are and making it easier to move between pages open within their browser. The page title is the first thing that a screen reader says when a user calls up a page.

2 - Text alternatives for every image

Text alternatives ("alt-text") describe & convey the purpose of an image, picture, illustration, chart, etc. An alt-text should be concise yet descriptive. Charts and graphs need particularly detailed descriptions of the data they represent. Screen readers read out the alt-text to people who cannot see the image, but also to people who have turned off images to speed up their download or to save bandwidth.

3 - Proper semantic markup

The proper use of HTML tags (h1, h2, h3 headings, lists, links etc.) structures content in a logical and meaningful way. This creates a clear document outline and helps assistive technologies, like but not limited to screen readers, to understand the relationship between different pieces of content. Using semantic HTML also improves SEO and makes your code more maintainable.

4 - Colour and contrast

Sufficient colour contrast between text and background makes content readable for users with visual impairments, but also for those users viewing screens in bright sunlight. The WCAG guidelines recommend a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text.

Avoiding colour dependency means not relying solely on colour to convey meaning, so that all elements, not just text and background, work in grayscale and are identifiable & readable for users with visual impairments, but also for those users viewing screens in bright sunlight.

5 - Keyboard usage

Not everyone can or wishes to use a mouse. The most popular alternative is the keyboard. That means that all functionality must also be accessed and navigated using only a keyboard - using the Tab key. Interactive elements should be reachable in a logical order using the Tab key, and custom widgets should implement standard keyboard patterns.

Navigating with the keyboard moves the focus through the interactive elements of the website. The style of the visual focus should make it clear which elements have keyboard focus, thus enhancing the experience for keyboard-users. Focus styles should be highly visible and consistent throughout the interface, with sufficient contrast against the background. Various visual indicators are available: Outlines, background colours, or underlines etc.

6 - Design of forms

Best practices for form design include clear labels, appropriate handling of validation errors, and ensuring that form controls are keyboard-operable. Required fields should be visually and programmatically indicated. Use error messaging that doesn't rely solely on colour (aka colour independence).

Once the absolute minimum has been implemented, these advanced techniques can be implemented. To be clear, these are not as easy as the basic steps above, but they will, sooner or later, result in fines where they are not implemented.

7 - The 1-Pixel trick for hidden labels

Writing descriptive links and buttons can sometimes lead to uncomfortabely long strings of text. The 1-Pixel trick utilises a css technique to hide unduly long pieces of text strings while keeping the text accessible to screen readers. This trick can also be used to augment & differentiate non-specific links (e.g. "read more" or "details"). The technique involves placing some explanatory text into a 1-pixel box (using a span tag). The box stays inline with a hidden overflow.

8 - Transcripts and captions

Text transcripts and closed captions (aka subtitles) for audio & video content ensures accessibility for users who are deaf or hard of hearing, or find themselves in a noisy environment, or simply prefer reading to listening. Transcripts should include all spoken dialogue and important sound effects, while captions should be synchronized with the audio and identify speakers when necessary.

Up to this point it's been about making static content accessible. The real challenge is making interactions & interactivity accessible. The Web Accessibility Initiative and the Accessible Rich Internet Applications (aka WAI-ARIA^*) provides direction on how to improve the accessibility of web applications. Where the Web Content Accessibility Guidelines (WCAG) focus more on static web content, WAI-ARIA focuses on making interactions more accessible.

9 - WAI-ARIA^* attributes

Leverage WAI-ARIA^* attributes to provide additional semantic information and improve the accessibility of dynamic content and user interface components. This includes using roles, states, and properties to convey information about UI widgets, live regions for dynamic content updates, and landmarks for page structure. ARIA should be used as a supplement to semantic HTML, not a replacement.

* WAI stands for Web Accessibility Initiative
* ARIA stands for Accessible Rich Internet Applications
Together they are a set of HTML tags and attributes standardized by the W3C (World Wide Web Consortium) in order to make rich internet applications accessible to assistive technology.