Accessibility
How to make your site usable for visitors with disabilities — what you do, what your theme does, and what Basker handles automatically
Making your site usable for visitors with disabilities — including those using screen readers, keyboard navigation, or assistive technology — is shared responsibility between you (the content), your theme (the rendering), and Basker (the platform). This page covers your part.
For developer-level accessibility documentation about how a theme implements accessible patterns, see basker.dev.
What you control as an editor
Most accessibility comes from content choices. The most consequential are:
Alt text for images
Every image you upload should have alt text that describes what the image conveys. Screen readers read the alt text aloud; search engines use it to understand the image; visitors on slow connections see it when an image fails to load.
Good alt text:
- Describes what's in the image, not the fact that it's an image. Don't write "Image of...".
- Is concise — under 150 characters is a useful rule of thumb.
- Captures the meaning, not every detail. For a photograph of a conductor mid-gesture, "Marin Alsop conducting at the Royal Albert Hall" is enough.
- Is empty (
""or blank) for purely decorative images that carry no information. An empty alt is a deliberate choice that tells screen readers to skip.
Set alt text in the Media library for any image, and again in any block that uses the image (where blocks expose alt fields, they typically default to the library value).
Heading structure
Headings give a page its outline. Visitors using screen readers navigate by jumping between headings; search engines use heading structure to understand a page. Get the structure right and the page works for everyone.
- Don't skip levels. After an H2, the next heading should be an H3, not an H4.
- Use only one H1 per page. Most themes render the page title as the H1 — don't add another.
- Headings should describe the content that follows, not just decorate it.
Link text
Make links describe their destination. "Click here" and "read more" are accessibility anti-patterns — screen readers can list links separately, and a list of "read more" entries is useless.
Good: [Read the season programme](/posts/2026-27-season-overview)
Bad: [Click here](/posts/2026-27-season-overview) to read the season programme
Captions and transcripts for audio and video
Audio and video content needs equivalents:
- Video — captions for spoken dialogue, plus a description for important visual content.
- Audio — a written transcript.
- Live or recorded performance excerpts — brief contextual descriptions in the page copy alongside the embed.
Where you add an audio or video block, look for fields like Caption, Transcript, or Description — fill them in.
Plain language
Write at the reading level your audience expects. Performing-arts content can be technical, but jargon and dense prose make sites harder to use for everyone — visitors with cognitive disabilities, visitors reading in a second language, and visitors in a hurry. Where a simpler word works, use it.
What your theme controls
Your theme is responsible for the technical accessibility of every page — keyboard navigation, focus indicators, colour contrast, ARIA roles, semantic HTML, screen-reader-friendly markup. A custom theme built for an accessibility-aware audience handles these well by default.
If you find specific pages or interactions on your live site that don't work with a screen reader or keyboard, that's a theme-level issue. Document the steps to reproduce and contact your theme developer. The Theme logs area can sometimes surface accessibility-related warnings.
What Basker handles automatically
Basker handles a few cross-cutting concerns so you don't have to:
- Form labels are tied to their inputs in the markup, so screen readers announce them correctly.
- Form errors are announced to assistive technology when validation fails.
- Skip links to jump past navigation are added by themes that opt into them.
- Image markup uses the alt text and dimensions you provide, so layouts don't shift as images load.
- HTTPS is on for every page, which is a baseline some assistive tools require.
Making event content accessible
Event records have a few accessibility-specific opportunities:
- Use the Custom attributes system to add accessibility-service fields to events — captioned performances, audio-described performances, signed performances, relaxed performances. Tag the relevant event instances with the services available at each.
- Smart collections can then list "captioned performances this season" or "all signed events" as their own pages. See Smart collections.
- For venue accessibility (step-free access, accessible parking, induction loops), put the detail on the Venue record so it appears consistently wherever the venue is referenced.