Our standard and policy
We build Alps, this website and our help content to the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA. Our ICT Accessibility Policy also covers the curriculum content we prepare for schools and the documents we provide, as described below. It sets how we design, build, test, fix and report on accessibility, and who is responsible for each part.
- New and changed screens are designed and built to WCAG 2.1 Level AA.
- Before release, our policy requires every change that adds or changes a screen to be checked with automated accessibility tests and a keyboard walkthrough.
- We review the accessibility of third-party components before we build them into Alps.
- Images in the content we prepare carry text alternatives. Captions on lesson videos from other publishers are up to their owners: we check for them and tell the curriculum’s owner about any that are missing.
- Our policy requires accessibility training for the core UI/UX developers who build and test Alps, when they join and every year after.
Where Alps stands today
Our Accessibility Conformance Report (VPAT 2.5, International Edition) rates Alps against WCAG 2.1, the Revised Section 508 standards and EN 301 549. Alps partially conforms to WCAG 2.1 Level AA: the report names each gap and the work planned to close it. We revise the report at least once a year, and the next revision evaluates the WCAG 2.2 criteria and adds the block-based programming editors.
How we test
- Automated scans of the running application with axe-core, using the WCAG 2.0 and 2.1 Level A and AA rules, on student, teacher and shared screens at desktop, tablet and narrow mobile widths.
- Keyboard walkthroughs of every screen, checking that focus is visible, moves in a sensible order, and never gets trapped.
- Structural checks of page titles, headings, landmarks, reading order, reflow at narrow widths, text spacing, and the announcements screen readers make for status messages and errors.
- A code editor audit of keyboard entry and exit, accessible names and instructions, across the major browser engines.
- Screen reader checks with VoiceOver, with full passes using VoiceOver and NVDA on our roadmap.
- Review by hand of the criteria that need human judgment. We report a criterion we have not yet examined as not evaluated rather than claim it.
How we fix problems
We track every accessibility problem, whether our testing finds it or a user reports it, and fix the ones that keep someone from completing a task first. Each fix is checked the same way the problem was found. The gaps in our conformance report, and the dates for fixing them, are part of our product roadmap.
Using Alps with assistive technology
- Apart from the block-based editors below and a few controls, Alps works from the keyboard, and the focus is always visible. In the code editor, Tab indents code; press Esc, then Tab, to move on. The controls that still need a mouse include some of the handles that resize Sandbox panels, a few controls on the sign-in page, and the grid teachers use to group students. Our VPAT lists them all.
- Pages have headings and landmarks, and controls have names. Autosaves and most confirmations and errors are announced to screen readers, and program output appears in a log your screen reader can read.
- Pages reflow up to 400% zoom, and a Windows contrast theme applies to Alps. Status is never shown by color alone.
- Parsons problems can be solved with the arrow keys instead of dragging.
- The block-based programming editors, Snap! and AlpsBlocks (built on the Scratch editor), come from their open-source makers and don’t yet work with screen readers. Snap! can build and edit scripts from the keyboard and enlarge its blocks; AlpsBlocks needs a mouse or touch screen to arrange blocks.
The help article “Accessibility in Alps,” inside Alps, has more detail, including what doesn’t fully work yet.
If something doesn’t work for you
- Email support@alps.2sigma.us with “Accessibility” in the subject. We reply within one business day.
- Within two business days, we’ll work with your teacher on another way for you to complete the task, such as turning in the work outside Alps for your teacher to grade.
- We track the problem until it is fixed, and let you and your teacher know when the fix is released.
For schools and districts
Our Accessibility Conformance Report (VPAT) and our ICT Accessibility Policy are available on request, and the report is included in our proposals. If anyone at your school or district needs a document we’ve sent you in a form that works with their screen reader or other assistive technology, ask us and we’ll provide one.
Contact
Email support@alps.2sigma.us to report a barrier, ask for help with a feature, or request our VPAT, our ICT Accessibility Policy, or any information in another format. We reply within one business day.