WordPress Accessibility Guide for Irish Businesses: Building WCAG-Compliant Websites

WordPress accessibility is the practice of building websites that can be used by everyone — including people with visual, auditory, motor, or cognitive disabilities. In Ireland, as in the wider EU, WordPress accessibility is increasingly becoming both a legal obligation and a business expectation. For Irish businesses building or maintaining WordPress sites, understanding WordPress accessibility requirements is no longer optional — and getting it right from the start is far easier than retrofitting it later.

What Is WordPress Accessibility?

Over 13% of the Irish population lives with a disability of some kind. WordPress accessibility ensures these users can access your website effectively — whether they use a screen reader (software that reads page content aloud for visually impaired users), a keyboard instead of a mouse (for those with limited motor control), or require high-contrast display settings (for users with low vision or colour blindness).

Good WordPress accessibility practices benefit everyone, not just people with disabilities. Captions on videos help users in noisy environments or who process information better through text. High contrast helps users reading on bright outdoor screens. Clear heading structures help all users scan content quickly. Accessible sites also tend to have better SEO — clear heading hierarchies, descriptive image alt text, and logical content structures help search engines understand your content just as they help screen readers.

WCAG 2.1 Explained for Irish Businesses

The Web Content Accessibility Guidelines (WCAG) 2.1 are the internationally recognised standard for WordPress accessibility, maintained by the W3C. The guidelines are organised around four principles — known by the acronym POUR:

Perceivable: All content must be presentable to users in ways they can perceive. This means: all images must have descriptive alt text; videos must have captions; audio content needs transcripts; text must have sufficient colour contrast (minimum 4.5:1 ratio for normal text, 3:1 for large text); and content cannot be communicated through colour alone.

Operable: All functionality must be accessible via keyboard. Users must be able to navigate, click buttons, activate menus, fill in forms, and submit them using Tab, Enter, Escape, and arrow keys — without a mouse. No content should flash more than three times per second (seizure risk). Users must have enough time to read and use content.

Understandable: The language of the page must be declared in HTML so screen readers use the correct pronunciation. Navigation must be consistent across pages. Error messages must be descriptive — “Please enter a valid email address” rather than just “Error.” Instructions must not rely on shape, colour, or position alone.

Robust: HTML must be valid and correctly structured. ARIA attributes must be used correctly. Content must be accessible with current and future assistive technologies.

WCAG 2.1 Level AA is the legal standard in most jurisdictions and the appropriate target for Irish business websites.

Legal Requirements for Irish Websites

• Public sector websites and apps in Ireland must comply with WCAG 2.1 Level AA and publish a formal accessibility statement, under the European Union (Accessibility of Websites and Mobile Applications of Public Sector Bodies) Regulations 2020.
• European Accessibility Act (EAA): From June 2025, private sector businesses providing e-commerce, banking, transport, telecommunications, and certain other services must comply with accessibility requirements. The EAA significantly expands the scope of mandatory accessibility beyond the public sector.
• Equal Status Act 2000: Irish equality law prohibits discrimination in the provision of goods and services. An inaccessible website that prevents a person with a disability from using your service could constitute discrimination under Irish law, regardless of intent.

Common WordPress Accessibility Issues

• Missing or inadequate image alt text: Images with empty alt text are invisible to screen readers. Decorative images should use alt=”” to indicate they can be ignored; meaningful images need descriptive alt text.
• Poor colour contrast: Light grey text on white backgrounds is the most common contrast failure. Use a contrast checker before finalising your colour palette.
• Non-keyboard-accessible menus: Drop-down navigation menus that activate only on mouse hover are completely inaccessible to keyboard users. All menu items must be reachable and activatable with Tab and Enter.
• Form fields without labels: Every input field must have a visible, programmatically associated label element. Placeholder text alone is not sufficient — it disappears when the user starts typing.
• No skip navigation link: Keyboard users must tab through every navigation item on every page unless a “Skip to main content” link is provided at the top of the page.
• Videos without captions: All pre-recorded video with audio content must have captions. Auto-generated captions from YouTube or Vimeo are a reasonable starting point but often need manual correction for accuracy.
• Improper heading hierarchy: Jumping from H1 directly to H4, or using heading tags purely for styling (making something an H2 because you like its font size), confuses screen reader users who navigate by headings.
• Low-contrast links: Links must be distinguishable from surrounding text by more than colour alone — underlines are the safest approach.

Making Your WordPress Site Accessible

Semantic HTML

Use the correct HTML elements for their intended purpose. Navigation in <nav>, main content in <main>, articles in <article>, sidebars in <aside>. Use <button> for clickable controls (not styled <div> or <span> elements). Use <a href> for links that navigate somewhere. Semantic HTML is the foundation of accessibility — it provides meaning that styling alone cannot convey.

ARIA Roles and Labels

Where semantic HTML is insufficient, ARIA (Accessible Rich Internet Applications) attributes provide additional context for assistive technologies. Key ARIA attributes: aria-label (names an element when visible text is absent), aria-describedby (associates a description with an element), aria-expanded (indicates open/closed state for menus and accordions), aria-live (announces dynamic content changes). Use ARIA to supplement HTML, not to replace it — the first rule of ARIA is “don’t use ARIA if a native HTML element exists for the purpose.”

Focus Management

Keyboard focus — the visible indicator of which element is currently active — must always be visible and must follow a logical order through the page. Never use CSS to hide the default focus outline without replacing it with a clearly visible alternative. The WCAG 2.2 Focus Appearance criterion requires that the focus indicator meets minimum size and contrast requirements.

Colour and Contrast

Use a colour contrast checker (WebAIM’s is free at webaim.org/resources/contrastchecker/) to verify every text/background colour combination in your design. The most common failure point: body text colour against background colour. Ensure you also check interactive elements (buttons, links) in all their states (default, hover, focus, active).

Images, Video, and Media Accessibility

Every image that conveys meaning must have descriptive alt text. The description should convey what the image communicates in context — not just what the image shows. An image of a developer at a computer on a “services” page might have alt text: “OnWebPoint developer building a custom WordPress website for an Irish business.” A purely decorative image (a background texture, a divider line) should use alt=”” to tell screen readers to skip it.

For complex images like infographics, charts, or diagrams, alt text alone may be insufficient — provide a detailed text description in the page content or in an adjacent expandable section. SVG graphics should have a <title> element and an aria-labelledby attribute pointing to it.

Making WordPress Forms Accessible

Forms are a critical interaction point on most Irish business websites — contact forms, quote request forms, booking forms. For each form field: use a visible <label> element associated with the input via the for attribute; never rely on placeholder text as the sole label; provide clear, specific error messages adjacent to the failed field; group related fields with <fieldset> and <legend>; and ensure the form can be submitted and all fields interacted with via keyboard alone.

WordPress Accessibility Plugins

• WP Accessibility: Free plugin that addresses common accessibility issues — adds a “Skip to main content” link, improves WordPress’s built-in accessibility shortcomings, and provides language declaration tools.
• Accessibility Checker by Equalize Digital: Scans your posts and pages for WCAG violations and provides a report with specific fixes. Excellent for ongoing accessibility monitoring and auditing.
• One Click Accessibility: Adds a frontend accessibility toolbar allowing users to increase text size, enable high contrast mode, underline links, and toggle other accessibility features.

Testing Your Site’s Accessibility

• WAVE (wave.webaim.org): Enter your URL to get a visual accessibility report overlaid on your page, showing errors, alerts, and structural elements with detailed explanations.
• Axe DevTools (browser extension): Runs automated WCAG tests and identifies violations with specific fix guidance. Available as a free Chrome and Firefox extension.
• Google Lighthouse: Built into Chrome DevTools — provides an accessibility score alongside performance and SEO scores. Good for catching obvious issues quickly.
• Manual keyboard testing: The most important test. Navigate your entire site using only Tab, Shift+Tab, Enter, Escape, and arrow keys. Confirm you can reach and activate every interactive element.
• Screen reader testing: NVDA (free for Windows) or VoiceOver (built into Mac and iPhone) allow you to experience your site as a blind user does. Even an hour of screen reader testing reveals issues that automated tools miss.

Automated tools catch roughly 30–40% of WCAG violations. The remainder require manual testing and human judgement. Build WordPress accessibility testing into your regular QA process rather than treating it as a one-time audit.

Need a WordPress accessibility audit or an accessible WordPress build for your Irish business? OnWebPoint builds WCAG-compliant WordPress sites.