Improve

TYPO3 Accessibility to BITV 2.0 and the BFSG

Accessibility arises in two places: in the sitepackage and in the daily editorial work. The technical side can be built right once. Whether it stays that way is decided afterwards, with every new piece of content.

Two levels you cannot separate

The technical part is the foundation: markup with meaningful semantics, sufficient contrast, operation without a mouse, a visible focus, tap targets you can hit on a phone. That can be laid down correctly once in the sitepackage.

The editorial part is created afresh every day. Every image calls for a decision about its alternative text, every heading one about its level, every link a text that makes sense outside its sentence. Without that level, the best technical foundation is used up again within six months.

Contrast is a decision about colour, not about taste

The most common conflict in these projects: a house colour that fails the required contrast on a light background. The reflex is to adjust the brand, which meets understandable resistance.

The better route is a second colour value for body text that keeps the same saturation and is only darker. The brand colour stays where it works: on filled areas, at large type sizes, and on dark backgrounds. The identity stays recognisable and the text stays readable.

Document it honestly

An accessibility statement includes a note of known limitations. That feels uncomfortable and is still the better route: a statement claiming completeness does not survive the first audit.

So we record what has been reached, what is still open, and when it will be tackled. That can be checked, which makes it more solid than a blanket claim.

What it involves

Auditing where you stand

Automated testing for the measurable criteria, manual review for everything a tool cannot see: keyboard operation, focus order, alternative texts that actually describe the image.

Implementation in the sitepackage

Semantic markup, sufficient contrast, a visible focus, operable tap targets and a heading hierarchy without jumps.

Making the editing side safe

Content elements built so that the obvious way to use them is also the accessible way. A required field for the alternative text rather than a polite request.

Forms

Labels tied to their fields, error messages people can understand, and operation that works without a mouse.

Training

What editors hold in their own hands: alternative texts, headings, link text that says something, tables with header rows.

The accessibility statement

The formal statement, with an honest account of known limitations and a way to report problems.

Common questions

Does the BFSG apply to us at all?

The German Accessibility Strengthening Act covers certain products and services in consumer business, e-commerce among them. Public bodies are already subject to BITV 2.0 in any case.

Whether your case falls under it is a legal question, and we do not answer legal questions. We implement the technical requirements and tell you what standard the site reaches afterwards. The legal classification belongs in expert hands.

Is an automated test enough?

No. Tools reliably find what can be measured: missing alternative texts, insufficient contrast, missing labels. That is a useful part, and only a part.

Whether an alternative text actually describes the image, whether the tab order makes sense, and whether the site can be operated without a mouse: no automated test sees any of that. Those checks are done by hand.

What can our editors break?

Quite a lot, usually without noticing. Headings chosen for how they look. Alternative texts that repeat the file name. Link text such as click here, which means nothing outside its sentence. Tables used for layout.

So we build the content elements so that the convenient route is the correct one, and train for the rest. Technology alone does not hold the state.

Can an existing site be retrofitted?

Usually yes, with varying effort. Contrast and focus styling are comparatively quick to fix. It gets more involved when the structure of the markup is wrong or custom interactive elements were built without keyboard support.

So it starts with an audit that shows what takes little effort and what would be a larger intervention.

Where does the site stand today?

We will look at the current state and sort the findings by effort and effect. That turns into an order of work you can actually get through.