Accessible websites / WCAG-aware delivery
Accessible website development with quality that is tested in practice.
We design and develop accessible websites with semantic code, keyboard and assistive-technology testing, clear documentation and delivery aligned with the requirements of each organisation, procurement or ESPA programme.
What does real accessibility mean?
It is not a separate version of the website. It is quality built into the same experience.
Accessibility affects structure, content, design, code and everyday publishing. The goal is to let people perceive information, navigate, understand what is happening and complete an action in different ways.
WCAG turns that principle into testable criteria. It does not replace human evaluation, and it does not turn an automated score into a certificate.
Perceivable · Operable · Understandable · Robust
Four principles that influence every component and every content decision.
These principles are not a decorative checklist. They become acceptance criteria for templates, journeys and dynamic functionality.
Perceivable
Text, images, audio and interface states need alternatives that allow people to perceive the same essential information in different ways.
Operable
Navigation, controls and forms must work with a keyboard and with different input methods, without traps or hidden actions.
Understandable
Structure, instructions, labels and error messages need to be clear, consistent and predictable throughout the journey.
Robust
Semantic code must be interpreted reliably by current browsers and assistive technologies as the site evolves.
Accessibility scope
Accessibility is built across the journey, not only on the homepage.
Evaluation uses representative templates, real content and critical actions such as search, forms, accounts or checkout.
Semantic structure
Landmarks, headings, lists, tables and controls are used according to their purpose, so the page retains meaning beyond its visual presentation.
Keyboard and focus
Every essential action remains available without a mouse, with visible focus, a logical order and no keyboard traps.
Contrast, zoom and reflow
Colour, typography and responsive behaviour are tested at increased zoom and narrow viewports without losing information or functionality.
Images, video and files
Alternative text, captions, transcripts and accessible documents are planned around the purpose of the content rather than treated as mechanical fields.
Forms and messages
Labels, instructions, required fields, validation, errors and status messages help people complete an action and recover when something goes wrong.
CMS and editorial rules
Templates, Gutenberg blocks and content guidance reduce the risk of new barriers when a team publishes pages, images or links after launch.
Automated + manual testing
Tools identify patterns. People verify whether the journey can actually be completed.
Automated checks are useful for repeatable technical errors. They cannot fully understand meaning, reading order, the quality of alternative text or the real behaviour of a custom component.
- Automated scans across agreed templates
- Keyboard-only navigation and visible focus
- Zoom, text spacing and responsive reflow
- Forms, errors and dynamic announcements
- Representative screen-reader checks
- Retesting after remediation
ESPA, procurement and contractual requirements
We read the active requirement first. Then we define the technical scope.
We do not present every accessible website as automatically eligible expenditure and do not promise acceptance into a funding programme. Requirements vary by call, organisation, sector and date.
Send us the technical annex or active call ↗︎- 01
Exact standard and level
We document whether the requirement specifies a WCAG version and level, EN 301 549, a statement or particular testing evidence.
- 02
Eligible scope
The beneficiary and funding adviser confirm which work is covered and which evidence or invoices are required.
- 03
Technical proposal and deliverables
We define templates, functionality, testing, remediation, documentation and anything outside the agreed scope.
- 04
Evidence before acceptance
Evaluation uses the real content and critical journeys before the project is treated as complete.
Accessibility-relevant work
Projects with different interaction, content and usability requirements.
These case studies show relevant design and technical decisions. They are not presented as independent WCAG conformance certificates.
Noema Home
A large bilingual catalogue with defined requirements for accessibility, readability and responsive use.
View the case study ↗︎
Olympism Culture
Sequential instructions and visual choices organise a complex process for a parent and child.
View the case study ↗︎
NAK Epignosi
A lightweight static foundation, clear hierarchy and direct access to services, details and contact information.
View the case study ↗︎From requirement to evidence
Five stages for a testable and maintainable result.
Accessibility is present in the brief, design, development and content workflow—not added as a scan on the final day.
- 01
Requirements and scope
We document the audience, functionality, technology, content and the exact requirements of the organisation, procurement or funding call.
- 02
Accessible UX and content
We design hierarchy, navigation, components, forms and language together with states, focus behaviour and alternative formats.
- 03
Semantic development
We use native elements where appropriate, controlled ARIA where necessary and responsive behaviour that does not depend on a pointer or colour alone.
- 04
Testing and remediation
Automated checks are combined with manual keyboard, focus, zoom, reflow, form and representative assistive-technology testing.
- 05
Evidence and handover
We deliver findings, fixes, known limitations and editorial guidance, with a defined scope for future reviews.
Standards, not slogans
The project is grounded in defined requirements and official sources.
WCAG 2.2 is the current W3C Recommendation. EN 301 549 and European or national requirements may set a different contractual baseline. Their application depends on the organisation and service; this page is not legal advice.
Start with the requirement
Let us read what the website must meet before we commit to a scope.
Send the current URL, critical user journeys and, where relevant, the procurement document, funding call or technical specification that defines the requirements.
Request an initial assessment ↗︎FAQ
Frequently asked questions about accessible websites, WCAG and ESPA.
Clear answers separate real technical scope from a widget, an automated score or a blanket promise of conformance.
What is an accessible website?
It is a website whose content and essential functionality can be used by people with different visual, auditory, motor or cognitive needs, with or without assistive technology. Accessibility is not a separate version of the site; it affects how the same experience is designed, written, developed and maintained.
Which version of WCAG do you use?
We use WCAG 2.2 as a current technical baseline where it is appropriate for the project. When a contract, procurement document or funding call specifies a particular version, level or EN 301 549, that exact requirement is recorded in the scope and takes precedence.
Can you guarantee complete WCAG compliance?
We do not make a blanket promise without a defined scope, representative content and evaluation. We can design and test against agreed criteria, document the results and disclose known limitations. Future content changes and third-party systems still require ongoing review.
Is an accessibility plugin or widget enough?
No. A widget may provide certain user preferences, but it cannot repair incorrect semantics, keyboard traps, forms without labels, inaccessible documents or problems inside custom components. The underlying design, code and content must be addressed.
Is accessibility mandatory for every ESPA funding programme?
There is no single answer for every call. Eligible expenditure, standards, evidence and deadlines are defined by the active programme and its contractual documents. We define the technical scope; the beneficiary and funding adviser confirm eligibility and the application process.
Can an existing website be made accessible?
Yes, but the work starts with an audit. The scope depends on the theme, plugins, page builder, content, forms, files and third-party services. Some issues can be remediated directly, while others may require component, template or full-platform changes.
Do you support WordPress, WooCommerce, OpenCart and custom websites?
Yes, using a platform-specific method. For WordPress and WooCommerce we examine the theme, blocks and plugins; for OpenCart, the template and checkout extensions; and for custom systems, the actual component and front-end code.
How do you test a website?
We use automated tools for repeatable technical findings and manual checks for keyboard access, focus, zoom and reflow, labels, errors, dynamic states and representative assistive-technology use. An automated score alone is never proof of conformance.
Do you test with a screen reader?
Within the agreed scope, we run representative screen-reader checks for landmarks, headings, links, controls, forms and dynamic announcements. The browser and assistive-technology combinations are documented in the test plan.
Who is responsible for accessibility after launch?
Accessibility is an ongoing responsibility. We provide guidance for headings, links, alternative text, video, PDFs and new blocks, but the publishing team must apply it. We can also provide scheduled audits or ongoing technical support.
Do we need an accessibility statement?
That depends on the organisation, applicable law and contractual framework. Where required, the statement should reflect a real evaluation, scope, known exceptions and a contact route rather than use generic boilerplate.
How much does an accessibility project cost and how long does it take?
It depends on the number of templates, functionality, the quality of the existing code and content, the required standard and the depth of testing. After an initial inventory, we provide a defined scope, stages and deliverables rather than a generic price.