WCAG 2.1 AA accessibility
Contrast ratios, keyboard operation, visible focus, text alternatives, correct heading hierarchy, accessible forms and tables. Tested with automated tools and by hand with a screen reader.
For public institutionsWCAG 2.1 AAECCC member
Public sector websites
For state and municipal institutions, publicly funded bodies, schools and public agencies. We work to the general requirements for public websites and the accessibility standard — not approximately, to the letter.
$ bj-a11y --standard wcag21aa --full
Contrast 4.5:1 — passKeyboard navigation — passForm labels — passHeading hierarchy H1→H3 — passText alternatives — pass$ bj-a11y --declaration
Accessibility statement draftedWCAG 2.1 AAEN 301 549ARIA
Accessibility audit and statement
Procurement documentation
Incident reporting to the NCSC
Administrator training
Scope of work
The requirements we work to
A public institution website is assessed against a checklist. Here is how we turn that checklist into technical work.
Mandatory structure and content
Institutional structure and contacts, legal information, areas of activity, services, dated news, data protection, anti-corruption, links to registers — with clear navigation and search.
Foreign language version
A separate language branch with its own URLs and correct hreflang linking, rather than automatic translation on the same address.
Security and logging
TLS configuration, hardened WordPress, separation of access rights, activity logs, backup policy and an incident procedure for internal rules.
Documents and open data
Document registers with search and filters, accessible alternatives to PDFs, machine-readable open data where required.
Handover and training
Administrator training, video instructions, technical documentation and a maintenance agreement so the institution works independently.
Process
How a project runs
Each stage ends with something you can review and sign off.
- Baseline auditWe check the current site for accessibility, structure, security and speed. The report doubles as the basis for a technical specification.
- Technical specificationWe draft or review the technical part of the procurement documents so the requirements are verifiable rather than declarative.
- Structure and designInformation architecture, accessible colour and typography systems, mockups for approval.
- ImplementationCustom theme, editor-friendly content fields, migration from the old system preserving URLs.
- Testing and statementAccessibility testing, speed and security checks, drafting the accessibility statement.
- Handover and maintenanceTraining, documentation, an update and monitoring agreement.
Watch out
Common problems we find
- A statement with no audit behind itThe statement exists but does not reflect the actual state of the site.
- PDF as the only formatScanned documents without a text layer are inaccessible to people and to search engines.
- Contrast "per brand guidelines"Light grey text on white does not meet the 4.5:1 requirement.
- Inaccessible menusDropdowns that work only with a mouse cut off keyboard users.
- Unsupported versionsOutdated WordPress and unpatched plugins are the most common breach cause in our investigations.
FAQ
Questions from institutions
Can you prepare the technical specification for a tender?
Yes. We draft the technical part with verifiable requirements — accessibility level, speed metrics, security measures, handover and maintenance terms. The institution uses it in its own procedure; it gives us no advantage and does not restrict other suppliers.
Do you carry out accessibility audits on their own?
Yes. The audit is a standalone service: you receive a report listing issues against WCAG 2.1 AA criteria, their severity, where they occur and how to fix them. We can also draft the accessibility statement.
What happens to the old content and URLs?
We migrate the content preserving existing URLs or setting up 301 redirects. This matters beyond search results — institutional URLs are often cited in legal acts, minutes and on other institutions' websites.
Can the site be hosted on our own server?
Yes. We deploy to your existing infrastructure or to our webhostas.com platform inside the EU. Either way you receive configuration documentation and a backup policy.
What if our website has already been breached?
Do not delete anything and do not restore from a backup — that destroys the evidence. Contact us; we will isolate the system, preserve evidence, determine the scope and prepare the report for the NCSC. Cleanup and recovery come afterwards.
Planning a website renewal?
Start with a baseline audit — it reveals the real scope and works as a basis for procurement documents.