Skip to content

Accessibility

How Wordfolk approaches accessibility, what is actually in place, and the gaps we already know about.

Last updated

1. What we are aiming for

We want Wordfolk to be usable by as many people as possible, including anyone browsing with a screen reader, a keyboard alone, magnification, or a browser configured for larger text.

Our target is the Web Content Accessibility Guidelines 2.2 at level AA. This is an aim, not a certified conformance claim. Wordfolk has not been audited by a third party, and we have not tested it against every assistive technology, so it would be dishonest to publish a conformance statement as though we had. What follows is what we have actually done and what we know we have not.

2. What is in place today

Reading and structure

  • Pages are built from real HTML landmarks (a header, a main region, a footer) and headings run in order without skipping levels, so a screen reader can navigate by structure.
  • Every page declares its language, so a screen reader pronounces it correctly.
  • Illustrations are decorative and marked as such, so they are skipped rather than announced as meaningless filenames.
  • Links are written to make sense out of context. You should not find a bare "click here" anywhere on the site.

Keyboard and focus

  • A skip link is the first thing you reach with the Tab key, and it jumps past the navigation to the page content.
  • Menus in the header can be opened and closed from the keyboard, close on Escape, and are hidden from assistive technology while closed rather than merely invisible.
  • Dialogs are attached to the page's top level rather than buried inside the card that opened them, which keeps their reading order and focus behaviour predictable.
  • Changes that happen without a page load, such as a saved blog or a submitted form, are announced through a live region rather than only shown.

Text and colour

  • Text sizes are set in relative units, so raising the default font size in your browser scales the site's type rather than being ignored.
  • Body text sits on a warm off-white background chosen for contrast, and the palette avoids relying on colour alone to convey meaning.
  • Layouts reflow rather than break down to about 320 pixels wide, and tables scroll inside their own box instead of forcing the page sideways.

Not depending on JavaScript

  • The public half of the site (the directory, categories, search, and every page like this one) is rendered on the server and readable with JavaScript disabled.
  • Filters and sorting are ordinary links with ordinary addresses, so they work without scripting and can be bookmarked or shared.
  • Hover and focus effects are written in CSS rather than driven by scripts, so they behave the same for a keyboard user as for a mouse user.

3. What we know is missing

Listing these is more useful than claiming they do not exist.

  • Reduced motion is not yet honoured. The site has small transitions and a fade-in on some content, and it does not currently check whether your system asks for reduced motion. It should, and that is the next thing on this list to be fixed.
  • Focus indicators are inconsistent. Form fields have a clear, deliberate focus style. Elsewhere the browser default is doing the work, which is adequate but not uniform, and on some backgrounds it is fainter than it should be.
  • No independent audit. Nothing here has been tested by an accessibility specialist, and our own testing with screen readers has been limited.
  • Colour contrast has not been measured everywhere. Body text and links were chosen with contrast in mind; some secondary and muted text has not been checked against the AA threshold in every context it appears.
  • The signed-in dashboard and admin pages are less tested than the public site. They are built as client-rendered applications and have had less scrutiny than the pages most people see.

4. Parts we do not control

Two parts of the experience are not ours to fix directly.

The bot check on our sign-up, password-reset, contact and newsletter forms comes from an outside supplier, so its accessibility is theirs rather than ours. If it stops you creating an account, email us and we will help you another way rather than leaving you stuck behind it.

Payment for a Featured placement happens on our payment provider's own checkout page, under their control. If you run into a barrier there, tell us, because we would want to know, and we can take payment details up with them.

Blogs listed in the directory are other people's sites, and their accessibility is not something we can speak for.

5. Telling us about a problem

If something here does not work for you, please tell us. A specific report is worth far more than a general one, so if you can, include the page address, what you were trying to do, and what happened instead, plus the browser and any assistive technology you were using, if you know.

Email hello@wordfolk.app. We aim to reply within five business days, and we will tell you honestly whether we can fix it and roughly when, rather than closing the conversation with an acknowledgement.

If you cannot reach part of the site at all and need the information in it, ask and we will send it to you another way.

6. How this page is kept current

This page was last reviewed on the date shown at the top, and it describes the site as it stood then rather than an aspiration for it.

We update it when something on the list of gaps is fixed, and when a change to the site introduces a new one. If you find something that belongs on that list and is not there, that is worth telling us about too.