Skip to main content

Elk Fire · Evacuation orders in effect. If your zone is set to Evacuate, leave now.

Details

Accessibility statement

Accessibility at The Slope

This is the whole picture: what we have built, what still does not work, and who answers when you write to us. If you are checking this page against a list, the sections are in the order you expect them.

Prepared August 8, 2026. Last reviewed August 8, 2026.

Conformance status

The Slope is partially conformant with WCAG 2.1 Level AA.

Partially conformant means most of the site meets the standard and some of it does not. We are not claiming full conformance and we are not calling ourselves compliant, because nobody has yet walked this site end to end with a screen reader. Until that happens, a stronger word would be a guess.

The parts we know fall short are listed below, each with the reason and the date we are working to. If you hit one that is not on the list, tell us and it goes on the list.

The standard we measure against

Web Content Accessibility Guidelines (WCAG), version 2.1, Level AA. That covers every Level A and Level AA success criterion.

Where this page names a criterion it gives the number, so you can look up what it covers instead of taking our word for it.

What we have done

Five things. The point of the first four is that accessibility is checked by the build rather than by whoever remembered.

  • It is built into the components, not added page by page

    Headings, buttons, form fields, dialogs, focus handling and the skip link all come from one shared design system. A fix lands everywhere the component is used, instead of on the one page somebody noticed.

  • The build fails on an accessibility error

    Our accessibility lint rules are errors, not warnings. An image with no description, a form field with no label, an invalid ARIA role or an empty heading stops the build before it can reach the site. The type check runs in the same gate.

  • An axe-core sweep runs on every release

    Every deployment is followed by an automated sweep with axe-core, running the WCAG 2.1 A and AA rule set over a fixed matrix of page types at three widths: desktop, phone, and the narrow width a page reflows to when a reader zooms in. Results are compared against a recorded baseline, so a rule that was not failing yesterday shows up as new.

  • A second suite tabs through the site

    Automated rule checking catches roughly a third of accessibility problems and it never touches a keyboard. A separate suite does: it checks that the first Tab reaches a working skip link (2.4.1), that the focus outline stays visible and no keyboard trap exists (2.4.7 and 2.1.2), that no page scrolls sideways at 320 CSS pixels wide (1.4.10 Reflow), and that nothing is clipped when a reader overrides text spacing (1.4.12).

  • One person owns it

    This statement, the mailbox below and the target dates in the next section are one person’s responsibility at The Slope, not a shared inbox’s. Ask us for their name and you get it.

What does not work yet

Everything we currently know to be short of the standard, with the reason and the date we are working to. A statement with nothing in this section has not been tested.

  • No manual screen reader audit has been done

    Nobody has yet gone through this site screen by screen with NVDA on Windows or VoiceOver on macOS and iOS, the way somebody who uses one every day would.

    Automated checks cannot answer the questions that decide whether a page is usable: whether an announcement makes sense, whether the reading order matches what you see, whether something interrupts at the wrong moment. Those need a person. Until that pass is done, the status above stays at partial.

    Target

  • Maps cannot be operated from a keyboard

    Panning, zooming and opening a marker need a pointer. The maps are graphics, and the mapping library underneath them does not offer those actions to the keyboard.

    Nothing is only on a map. Every place we plot is also listed as text on the same page, with the name, the address and the same detail the marker holds, so you can reach the information without the map. That is a workaround rather than a fix, and it stays on this list until the map itself answers to a keyboard.

    Target

  • Spanish is machine translated, and four languages translate only the interface

    Public notices, emergency alerts and organization pages are offered in Spanish. That Spanish is produced by machine translation. Every translated page says so on the page, and the English original is one click away and stays the official record.

    German, French, Portuguese and Italian translate the interface only. The notice or the alert inside that interface is still the English the agency published, and the page says so in the reader’s language rather than leaving them to work it out. A machine translation that says so is more use than none. One that hides what it is is worse than none.

    Target

  • Some older images have no description

    A verified government or civic entity cannot publish a photograph on an alert or a notice without a description. That gate does not reach backwards, so images uploaded before it existed, and photographs on older business listings, can still be missing one.

    We are working through the backlog one surface at a time, starting with emergency content, because that is where a missing description costs the most.

    Target

Technical specifications

Accessibility here relies on HTML, CSS, JavaScript and WAI-ARIA.

  • HTML
  • CSS
  • JavaScript
  • WAI-ARIA

JavaScript is required. With it turned off the site does not work. These technologies have to be supported by your browser and by any assistive technology running on the same device.

We check by hand in current versions of Chrome, Safari, Firefox and Edge. The automated sweep runs in Chromium.

How this was assessed

This is a self-assessment. The Slope evaluated its own site. No outside firm has audited it, and this page is not a third party conformance report.

The method is the axe-core rule set for WCAG 2.1 A and AA run against the live site across a matrix of page types at three widths, the keyboard suite described above, the accessibility lint gate on every build, and review by our own engineers using browser developer tools.

What that method cannot cover is a person using real assistive technology, which is the first item on the list above. When that pass is done, this section will say who did it and what changed.

What we do not claim

Some of what a platform could promise about accessibility should not be promised. These are the ones we get asked about.

  • We do not generate sign language

    There is no signing avatar on this platform and there will not be one. Deaf-led organizations have been clear about this. The World Federation of the Deaf, together with the World Association of Sign Language Interpreters, and the National Association of the Deaf in the United States, have objected to signing avatars being used in place of human interpreters. We agree with them.

    ASL here means one of two things: a video an entity had interpreted by a qualified human, or a link to the interpreted version they already publish on their own channel.

  • We do not keep a library of ASL clips

    American Sign Language has its own grammar and word order. It is not English on the hands. Clips cannot be assembled into a sentence, and a stock library could never sign the street, the zone or the time, which is the part of an alert that tells somebody what to do.

  • We do not generate captions

    There is no speech recognition in this stack and none is planned. Recognition mishears place names and numbers, and the message it is mishearing says evacuate.

    Captions come from a file a person wrote or checked. A verified entity cannot publish a video that has sound and no captions.

  • Where sign language sits in the standard

    Sign language is success criterion 1.2.6, at Level AAA, and it applies to prerecorded audio in synchronized media. Our target is Level AA, so 1.2.6 sits outside it. We are writing that down rather than leaving you to notice the omission.

  • Listen is not a screen reader

    Some pages carry a button that reads the text aloud. It is there for readers with low literacy or dyslexia, for people who zoom rather than run assistive technology, for readers on the interface-only languages, and for anyone whose hands and eyes are busy. It satisfies no success criterion and we do not count it as one. If you use a screen reader, use yours. Nothing here tries to talk over it.

  • We do not do an entity’s accessibility work for it

    A city, county, district or school publishing through The Slope is still responsible for its own documents, its own videos and its own website. We give them tools, and gates that refuse some of the worst outcomes, such as an alert photograph with no description or a video with sound and no captions. We cannot fix a PDF we did not write, and we do not claim to.

  • We do not promise delivery

    We control what is sent, when we accept it, and the record that it went out. Phone carriers, app stores and operating systems control whether it arrives. That belongs on this page because a message that never arrives is not an accessible message, and a guarantee that is not ours to give is not worth reading.

Tell us about a barrier

If any part of this site stops you, write to us. You do not need to know which rule it breaks or what the thing is called. The page you were on and what you were trying to do is enough.

What happens after you write

  • We acknowledge every accessibility report within 2 business days, so you know a person has it and who that person is.
  • We give a substantive answer within 10 business days: what we found, what we are doing about it, and when. If a fix will take longer than that, the answer says so and gives you a date.
  • Ask for our reply in a different format and you get it in that format.

If our answer is not good enough

Ask for it to be escalated, either in your reply to us or in a new message to the same address. An escalated report is answered in writing, within 10 business days, by somebody who did not handle it the first time.

A formal complaint can be sent in writing to the postal address below, marked for the accessibility owner. Tell us what you want done about it and we answer in writing.

If your complaint is about something a government or civic entity published through us, we pass it to that entity and tell you we have. Their document is theirs, and they are the ones who can change it.

Postal address

CM Ventures Inc. (DBA The Slope)321 South 1st Street #388Montrose, CO 81401

About this statement

Prepared by The Slope. Reviewed at least every six months, and again after any change to the shared design system.

It covers theslope.co and the mobile apps that load it. It does not cover a third party site we link to.

Date prepared
Last reviewed
Next review