Accessibility

1. The standard we are aiming at

The target is the Web Content Accessibility Guidelines 2.1, Level AA — the usual benchmark for a public-facing service, and the one US regulators and courts refer to.

Aiming at is not the same as meeting, and we are not going to blur the two. Claiming conformance would mean every page had been checked against every Level A and AA success criterion, by someone who did not write it, using the assistive technology people really use. None of that has happened. What has happened is described in section 3, and it is much less than that.

In plain English: We are trying to hit a known standard. We have not proved that we hit it, so we do not say that we have.

2. Why this matters more here than on an average site

ScholarBot asks you whether you have a disability, and uses the answer to match you to awards for disabled students. A service that asks that question and is then unusable by the people answering it is not a small irony — it is failing those students on the exact thing it asked them about.

That is also why this page is more blunt than most. The gap between what is tested and what is claimed is precisely the space a student falls into.

3. What is actually tested

One automated audit, run against the real running site rather than asserted in a document:

• It runs axe-core in Chromium against pages the browser has genuinely rendered.
• It uses the WCAG 2.0 and 2.1, Level A and AA rules only. Best-practice rules are excluded on purpose: mixing standards with opinions is how a check becomes noise everyone learns to ignore.
• Every page is checked at two widths — a 1280×900 desktop and a 390×844 phone — because a phone layout can reflow text over a background in a way the desktop one never does, and most of this audience is on a phone.
• Serious and critical violations fail the build. Moderate and minor ones are reported but do not, so some lesser issues may be outstanding at any given moment.

The pages it covers are the ones a stranger can reach: the home page, /tutorial, /pricing, /login, /terms, /privacy. That is the whole scope. This page is not on that list, and neither is anything else.

And an automated tool finds only certain kinds of problem. It is good at a missing label, a contrast failure, a broken heading order, an image with no alternative text. It cannot tell you whether a page makes sense read aloud, whether the keyboard path through a form is sane, or whether an error message tells you what to do about it. Nobody has checked those.

4. What is known to work

Each of these is built into the app rather than left to each page to remember, which is the only reason we are willing to state it:

• Keyboard focus is always visible. Anything you can focus draws a thick outline, set once for the whole app, with a gap so it stays visible against the control it is on.
• Controls are real controls. Buttons are buttons, links are links, fields are fields. The toggles and option circles that look custom are real checkboxes and radio buttons, visually hidden and styled — not a coloured box pretending to be one.
• Fields carry their labels. The shared field component wraps the control inside its own label, so the label cannot be broken by two fields sharing an id, and clicking the text focuses the field. Sets of related options are grouped so the question is announced once and each option only has to carry its own name.
• Dialogs are real dialogs. They use the browser’s own dialog element, so focus is trapped inside them, Escape closes them, and the page behind does not scroll — behaviour the browser provides and a styled box does not.
• Reduced motion is honoured everywhere. If your system asks for less motion, every animation and transition in the app is switched off. This is applied globally, so a new page cannot forget it.
• Text contrast is measured, not eyeballed. The colour system records the measured ratio beside each text colour it defines, against a rule of 4.5:1 or better on the page background.
• The public pages are plain server-rendered HTML. They are readable before any JavaScript arrives, which matters on school wifi and matters more with assistive technology in the middle. The page language is declared, so a screen reader knows which voice to use.

5. What is known not to work, or has never been checked

This is the part most accessibility statements leave out, so it is the part worth reading.

• There is no “skip to content” link. Every page that carries the app navigation — which includes this one — makes a keyboard user tab through the whole of it before reaching the page itself, every page, every time. This is a known gap, not an oversight we have just noticed.
• Nothing behind the sign-in has ever been audited. Your dashboard, profile, the eligibility questions, the essay coach, documents, applications, the loans guide — none of it is covered by the check in section 3, and no other check covers it either. Those are the screens you would use most.
• No screen reader has ever been used to test ScholarBot. Not NVDA, JAWS, VoiceOver or TalkBack. The markup is written to be read well; that is not the same as anyone having listened to it.
• No disabled person outside this project has tested it, and there has been no independent audit.
• The browser extension and our emails are outside the audit entirely. The extension’s popup and the mail ScholarBot sends you are not checked by anything automated.
• Non-text contrast is not measured. The ratios we record are for text. The contrast of icons, borders and the edges of form fields — WCAG 1.4.11 — has not been measured anywhere.
• Sponsors’ own sites are not ours. When you follow a link to a scholarship provider you are on a site we did not build and cannot change, and its accessibility is nothing we can promise. Tell us anyway — see section 6, because we can often get you what you need without that form.

In plain English: A machine checks the pages a stranger sees. The pages you would actually live in are checked by nothing, and no person using a screen reader has ever been asked whether any of it works.

6. Telling us something is in your way

Email support@scholarbot.org. A report is useful even if it is one sentence — “the eligibility questions do not work with my screen reader” is enough to act on. If you can add the page you were on, what you were trying to do, and what you use to browse, that helps, but none of it is required.

• We will reply. We will not promise a fix by a particular date, because a date invented to sound reassuring is worse than a plain answer about what we can do.
• If a deadline is involved, say so in the first line. Deadlines do not wait for a fix. Getting you an award’s details, its rules and its application link by email, so you can apply directly to the sponsor, is something we can usually do the same day.
• You do not have to tell us anything about your disability in order to report a problem. Nothing you say in that email is added to your profile, and it does not change what you are matched to. What you enter in the eligibility questions is the only thing that does, and that is covered in the Privacy Policy.

7. Keeping this page honest

Every claim above was written from the code rather than from a template, in the same way the Terms of Use and the Privacy Policy were. A test in this repository fails if the list of audited pages in section 3 stops matching the pages the audit really visits, and fails if this page starts claiming conformance it has not earned.

If anything here is out of date or you can show that it is untrue, that is a bug and we want to hear about it at the same address.