Website accessibility is not a final plugin or a box to tick before launch. It is a design, content and development discipline that helps more people perceive, understand and use a website, including visitors who navigate with a keyboard, screen reader, magnification or other assistive technology.
For a Malta business commissioning a new site or redesign, accessibility requirements should appear in the brief, proposal, design review, development tests and ongoing content process. This checklist helps buyers ask clearer questions and obtain evidence instead of relying on vague claims that a website is “fully accessible.”
Start by defining the website and its users
List the services and journeys the website must support. These may include finding contact information, requesting a quote, booking an appointment, buying a product, completing a form, reading a document or managing an account. Identify the pages, components and third-party tools involved in each journey.
Accessibility planning should cover the complete route, not only the homepage. A well-structured landing page does not help if the booking widget, payment screen or confirmation message cannot be used without a mouse.
Understand the legal context without guessing
The European Accessibility Act establishes accessibility requirements for specified products and services across the EU. The European Commission lists areas including ecommerce, consumer banking services and certain electronic communications and transport-related services. The exact obligations and exemptions depend on the organisation, service and national implementation.
Do not treat this article as a legal classification of your business. Ask an appropriately qualified adviser which Maltese and EU requirements apply to your organisation. Even where a particular legal duty does not apply, improving accessibility can remove avoidable barriers for customers and staff.
Use WCAG as a testable technical reference
The Web Content Accessibility Guidelines, or WCAG, provide internationally recognised success criteria organised around four principles: content should be perceivable, operable, understandable and robust. WCAG 2.2 identifies conformance levels A, AA and AAA.
Your web brief should identify the intended WCAG version and conformance target, together with any applicable legal standard. A common procurement approach is to specify WCAG 2.2 Level AA, but the correct requirement should be confirmed for the project rather than copied automatically.
1. Require semantic page structure
Pages should use meaningful headings, landmarks, lists, labels and controls. The visual appearance alone is not enough. A screen reader and other assistive technologies need programmatic information that describes the structure and purpose of the content.
- Each page has a clear, descriptive title and main heading.
- Heading levels follow a logical order.
- Navigation, main content and footer areas are identifiable.
- Buttons are implemented as buttons and links as links.
- Tables are used for tabular data, with suitable headers.
2. Make every essential action work with a keyboard
A visitor should be able to move through menus, forms, dialogs, carousels and interactive controls using a keyboard. The current focus must remain visible, the order should be logical and the user must not become trapped inside a component.
Ask the supplier to demonstrate the main journeys without using a mouse. This simple review often reveals problems that an automated scan cannot identify, such as an inaccessible menu or a modal window that loses focus.
3. Check colour contrast and non-colour cues
Text, icons and important interface elements need sufficient contrast against their background. Information should not depend on colour alone. For example, a form error should include a message or symbol rather than changing only from grey to red.
Check contrast during the design stage, including hover, focus, disabled and error states. Correcting an approved colour system is easier than repairing every page after development.
4. Provide useful image alternatives
Informative images need alternative text that communicates their purpose in context. Decorative images should normally be ignored by assistive technology. Charts and diagrams may need a nearby text explanation or data table rather than a short label.
Alternative text is also a content-management responsibility. Include guidance for staff who will upload news, products, case studies and blog articles after launch.
5. Design forms for real completion
Every field should have a persistent, programmatically associated label. Instructions should appear before they are needed. Required fields, expected formats and errors should be communicated clearly, and focus should move appropriately when a submission fails.
- Labels remain visible when a value is entered.
- Errors identify the field and explain how to correct it.
- Instructions do not rely only on placeholder text.
- Keyboard and screen-reader users can reach the submit control.
- Success and failure messages are announced and visible.
- Timeouts are explained and can be extended where appropriate.
Interactive elements often create accessibility problems. A carousel should provide controls, support keyboard use and avoid movement that cannot be paused. Dropdown menus should communicate their expanded state. Dialogs should receive and return focus correctly.
Do not assume a component is accessible because it came from a popular theme or plugin. Test the configured component in the actual website. Custom styling and scripts can alter otherwise sound behaviour.
7. Make video and audio usable
Plan captions, transcripts and audio descriptions where required by the content and applicable criteria. Media controls must also be accessible by keyboard and labelled clearly. Avoid unexpected audio and provide a way to pause moving or automatically updating content.
8. Support zoom, reflow and mobile use
Users should be able to enlarge text and zoom without losing information or being forced into impractical horizontal scrolling for ordinary content. Test narrow screens, portrait and landscape orientation, browser zoom and text spacing.
Responsive design and accessibility overlap, but they are not identical. A site can fit a phone screen while still having tiny targets, poor focus visibility or controls that assistive technology cannot interpret.
9. Include documents and third-party services
PDFs, booking engines, maps, chat tools, payment systems and embedded forms are part of the customer journey. Record who is responsible for each external component, what accessibility evidence is available and what alternative route exists if the component creates a barrier.
If important information appears in a downloadable document, consider whether an accessible HTML version should also be available. Avoid making a scanned image the only way to read essential content.
10. Combine automated and manual testing
Automated tools can identify certain code, contrast and labelling issues, but they cannot determine whether every heading is meaningful, alternative text is useful or a complete journey makes sense. A credible test plan combines automated checks with manual keyboard, screen-reader and visual reviews.
Define which browsers, devices, assistive technologies, templates and journeys will be tested. Keep an issue log containing the affected page, criterion, severity, evidence, owner and retest result.
What to request from a web-design proposal
- The accessibility standard and conformance target.
- The pages, templates and third-party components included.
- The design-stage contrast and interaction reviews.
- The automated and manual testing methods.
- The definition of an accessibility defect and acceptance process.
- The remediation period for issues found before launch.
- Training for staff who publish content.
- Evidence delivered at handover, including known limitations.
- Responsibility for testing future updates.
Add these requirements to your wider website development brief. Accessibility is easier to deliver when it forms part of scope and acceptance criteria from the start.
A practical launch review
- Complete the main journeys using only a keyboard.
- Review headings and landmarks with a screen reader.
- Check text, icons, focus states and errors for contrast.
- Verify labels, instructions and error recovery on forms.
- Confirm alternatives for images, audio and video.
- Test zoom, reflow and text spacing.
- Review documents and third-party services.
- Correct high-impact issues and retest them.
- Document known limitations and a remediation owner.
- Give content editors an accessibility checklist.
Accessibility should continue after launch
New articles, campaigns, plugins and design changes can introduce fresh barriers. Assign ownership, provide a way for users to report problems and schedule checks after material releases. An accessibility statement can explain the commitment, known limitations and contact route, but it does not replace testing or remediation.
Digital Consulting Pros provides web design and development in Malta. If you are planning a new website or redesign, contact DCP to discuss accessibility requirements alongside performance, SEO and conversion goals.
Authoritative guidance
- W3C Web Content Accessibility Guidelines 2.2
- W3C guidance on evaluating web accessibility
- European Commission overview of the European Accessibility Act
This article provides general design and procurement information, not legal advice. Featured photo by Andrey Novik on Unsplash.
