Accessibility

Our commitment

Arkansas Serve exists so people can find service opportunities where they live and get credit for the hours they give. That is only true if the site works for everyone using it, including people who navigate by keyboard, use a screen reader or magnifier, need larger text or higher contrast, or rely on voice control.

We target WCAG 2.1 Level AA — the Web Content Accessibility Guidelines published by the W3C — as the standard the platform is measured against. Accessibility is treated as a defect class here, not a project: a barrier is a bug, and it is fixed the way other bugs are fixed.

Conformance status

Arkansas Serve is partially conformant with WCAG 2.1 Level AA. "Partially conformant" means most of the platform meets the standard, and some parts do not yet. We are not claiming full conformance, and we would rather tell you exactly where we stand than publish a claim you would discover was untrue the first time you hit a problem.

Every known gap we have found so far is listed under Known limitations below. If you find one that is not listed, we want to hear about it — see Report a barrier.

How we test

Automated checks run against every proposed change to the site before it can be released. Those checks use axe-core, an open-source accessibility engine, configured to the WCAG 2.1 A and AA rules. A change that introduces a new violation fails the check and does not ship until the violation is resolved or deliberately accepted and recorded.

What those checks cover, precisely. Twenty-five pages, filled with representative data rather than left empty. Eighteen of them are pages anyone can reach without an account — the catalogue, the organization directory, an event page, an organization page and one of the profile pages for organizations listed from public records, the county pages, sign-in, the guardian and claim links, the policy pages, the not-found page and the page you are reading. The other seven are the pages you only see once you are signed in: your dashboard, and the tools organizations use to run events and manage volunteers.

On top of those, sixteen points partway through a task are checked in the state a person actually meets them in: the age-and-consent dialog, the profile editor, the event builder at two of its steps, logging hours, creating an organization, confirming a deletion, running an hours report, the catalogue with its filters opened, and each tab of the two administration screens.

We also record the cases the engine cannot decide. Where axe-core can measure a colour contrast it either passes or fails, but where it cannot — text over a gradient or an image, for instance — it returns "needs review" rather than a verdict. Those used to be discarded. They are now counted and compared like any other result, so a change that introduces a new one has to be looked at. This was added after a button whose label and background were the same colour passed a clean run: the engine had spotted it and we were throwing the answer away.

And what they do not. They do not submit a form and read back the error, so problems that only appear after something is rejected are found by hand or not at all — and they do not reach every dialog, only the sixteen above. A clean run means those pages and those states carry no automated violations; it does not mean the whole platform has been machine-checked. We would rather write that down than let a green tick imply more than it earned.

Automated testing is a floor, not a ceiling — it reliably catches only a portion of accessibility problems. We supplement it with manual keyboard-only passes and screen-reader spot checks on the flows that matter most: finding an event, viewing an organization, signing in, and a guardian granting permission.

Known limitations

These are the areas we know fall short today. Each is being worked on.

• Maps. The map used to show where events and organizations are is a third-party component, and panning or selecting pins on it is difficult or impossible without a mouse. Everywhere a map appears, the same information is also available as a text list, and the list is the accessible path — nothing is only on the map.
• Documents uploaded by organizations. Waivers, permission forms and similar files are supplied by the organizations that use the platform. We do not control how those files were produced, and some will not be tagged for screen readers. If you receive one you cannot read, contact us and we will get you the contents in a usable form.
• What happens after a form is rejected. Our automated checks reach the main dialogs and forms, but they do not submit one and read back the error message. If a validation message is hard to find or hard to read, that is a gap we would rely on you to tell us about — it is the part of a task our tooling does not see.
• Older listings brought in from other sites. Event descriptions collected from an organization's own website or calendar keep that organization's wording and structure, which we cannot rewrite. Headings and formatting inside those descriptions may not be well-structured.
• Anti-abuse challenges. Where a challenge is used to keep automated sign-ups out, it is supplied by a third party. If one blocks you, use the contact details below and we will complete the step with you directly.

If something is not usable for you

You do not have to wait for us to fix a barrier before you can use the service. If any part of Arkansas Serve is not accessible to you, contact us and we will do the task with you or for you — including searching for opportunities, registering for an event, logging hours, or supplying anything on the site in a different format. There is no charge and you do not need to explain why.

Report a barrier

Tell us what page you were on, what you were trying to do, and what happened. If you know what you are using to browse — a screen reader, a magnifier, voice control, a particular browser — that helps us reproduce it, but it is not required.

We aim to respond within five business days. Reports that block someone from using the service are prioritised over other work.

How this statement is kept current

This statement is reviewed at least once a year, and whenever a limitation listed above is resolved or a new one is found. The date at the top is the date it was last accurate. It was prepared by assessing the platform against WCAG 2.1 Level AA using the automated and manual testing described in How we test.

Security issues are handled separately — see our security contact.