The only complete law enforcement community policing package with ADA support built in.

A package, under agency control

One community policing package. Every public tool on the same accessible interface.

The OPS Community Interface is the public side of the OPS Network. It looks like a professional agency site. Underneath, it is the agency’s controlled portal for community partnership: secure, free for the public, and connected to other OPS agencies. Residents do not need an account to reach it, and many tools can be used anonymously.

• Live TIPSTwo-way tips with law enforcement
• AlertsTime-sensitive public notices
• Online reportingNon-emergency reports and follow-up
• Crime blotterPublic crime information
• Ask an OfficerDirect community questions
• CommendationsRecognize professional service
• Internal affairsHow to raise a concern
• Press toolsMedia information the agency controls
• NewsAgency updates in plain language
• Geo camera mappingMapped public safety information
• Documents and linksPolicies, forms, and resources
• Property and vacation checksResident service requests
• Missing petsCommunity lost-and-found reports
• NPS-AIDDisability identification support
• Recruiting portalAgency hiring, accessible to applicants

These tools sit inside the Community Interface, so keyboard access, screen-reader names, contrast, focus, language, and reflow apply to each of them. Online reporting modules — incidents, alarms, parking, road hazards, and related requests — follow the same standard. Staff turn the message over. They do not rebuild accessibility for every page.

The full Level AA set

Every WCAG 2.1 AA requirement, and how OPS injects it.

WCAG 2.1 Level AA is 50 success criteria: 30 at Level A and 20 at Level AA. They fall into four principles. OPS builds Community Interfaces to all 50, then keeps them there through the partnership. Level AAA is outside the DOJ technical standard and outside this conformance target.

Success criteria catalog

Showing all 50 success criteria.

• 1.1.1Non-text contentA

  Meaningful images and icons have text alternatives. Decorative images are hidden from assistive technology. A symbol is never the only way a service is identified.

• 1.2.1Audio-only and video-onlyA

  Community tools operate without requiring media. When an agency publishes prerecorded audio-only or video-only content, a transcript or text alternative is part of conformance.

• 1.2.2Captions (prerecorded)A

  Prerecorded video that includes sound is expected to carry captions so speech and meaningful sounds are available as text.

• 1.2.3Audio description or media alternativeA

  Visual information in prerecorded video has an audio description or a full text alternative. The interface itself does not hide instructions inside video.

• 1.2.4Captions (live)AA

  Live video that includes speech is expected to provide captions. Day-to-day tools such as alerts and reporting are text, so they do not depend on a live stream.

• 1.2.5Audio description (prerecorded)AA

  When prerecorded video shows information that is not already spoken, audio description is part of the conformance expectation for that content.

• 1.3.1Info and relationshipsA

  Headings, lists, landmarks, and form groups are in the HTML, so relationships are available to assistive technology and not only to someone who can see the layout.

• 1.3.2Meaningful sequenceA

  Reading order follows the visual order of each Community Interface, including on a phone.

• 1.3.3Sensory characteristicsA

  Instructions name the control in words. They do not rely on color, shape, or “the button on the right” alone.

• 1.3.4OrientationAA

  Interfaces reflow in portrait and landscape. No community tool is locked to a single screen orientation.

• 1.3.5Identify input purposeA

  Fields that collect personal information expose their purpose in code so browsers and assistive technology can identify and fill them.

• 1.4.1Use of colorA

  Links, status, and required fields are identified with text or another cue in addition to color. The agency accent color is never the only signal.

• 1.4.2Audio controlA

  Interfaces do not auto-play audio. If sound is present, the person can pause or stop it.

• 1.4.3Contrast (minimum)AA

  Text is presented at least at 4.5:1 against its background, and large text at least at 3:1. Agency color pairs are selected so the light and dark roles stay readable.

• 1.4.4Resize textAA

  Text can be resized to 200% with the browser’s own controls. Content stays on screen and controls keep working.

• 1.4.5Images of textAA

  Interface copy is real text that can be resized, translated, and read aloud. Logos are the limited exception. Agencies are guided to publish words as text.

• 1.4.10ReflowAA

  At 400% zoom, and on a narrow phone, content reflows in one direction. People are not forced to scroll both sideways and downward to use a tool.

• 1.4.11Non-text contrastAA

  Buttons, focus indicators, and meaningful icons meet at least a 3:1 contrast ratio against the colors next to them.

• 1.4.12Text spacingAA

  People can increase line height, paragraph spacing, letter spacing, and word spacing to the WCAG limits without clipping, overlap, or lost function.

• 1.4.13Content on hover or focusAA

  Navigation is visible blocs and the main menu, so services are not hidden in hover-only menus. Any extra content that appears on hover or focus can be dismissed and remains until the person moves away.

• 2.1.1KeyboardA

  Every control operates from the keyboard. A mouse or touch screen is never the only way to file a tip, read an alert, or open a form.

• 2.1.2No keyboard trapA

  Focus can always be moved away from a component with standard keys. Nothing captures the keyboard.

• 2.1.4Character key shortcutsA

  If a single-character shortcut exists, it can be turned off or remapped, or it runs only when its control has focus.

• 2.2.1Timing adjustableA

  Where a time limit is used, the person can turn it off, adjust it, or extend it, unless the limit is essential to the activity.

• 2.2.2Pause, stop, hideA

  Moving or auto-updating content can be paused, stopped, or hidden. OPS does not use carousels or decorative motion to present community services.

• 2.3.1Three flashes or belowA

  Nothing in the interface flashes more than three times in one second.

• 2.4.1Bypass blocksA

  A “skip to main content” link lets keyboard and screen-reader users move past repeated navigation.

• 2.4.2Page titledA

  Each view has a descriptive, unique title so people, and browser tabs, can tell interfaces and tools apart.

• 2.4.3Focus orderA

  Tab order follows the visual order of the page. Shift+Tab moves backward through that same order.

• 2.4.4Link purposeA

  Links and buttons say what they open or what they do. “Click here” is not the label for a service.

• 2.4.5Multiple waysAA

  People can reach content from the main menu, from flashcard blocs on the interface, and from other persistent paths. One hidden menu is not the only route.

• 2.4.6Headings and labelsAA

  Headings describe the section. Form labels describe the field. Agencies can keep titles plain without touching the code.

• 2.4.7Focus visibleAA

  A clear indicator shows which control has keyboard focus, including on a narrow screen.

• 2.5.1Pointer gesturesA

  Any action that uses a complex gesture also has a simple single-pointer alternative.

• 2.5.2Pointer cancellationA

  Actions complete on release, so a person can move off a control and cancel before it fires.

• 2.5.3Label in nameA

  The accessible name of a control includes the words that are visible, so speech input and screen readers match what is on screen.

• 2.5.4Motion actuationA

  Shaking or tilting a device is never the only way to trigger a function, and motion actuation can be turned off.

• 3.1.1Language of pageA

  The page language is set in the code, including after a community member changes language, so screen readers pronounce it correctly.

• 3.1.2Language of partsAA

  A passage in another language is marked in the code. The platform can present the interface in more than 100 languages that screen readers can follow.

• 3.2.1On focusA

  Moving focus to a control does not automatically open a new page, submit a form, or otherwise change context.

• 3.2.2On inputA

  Changing a field or setting does not automatically change context. The person decides when to submit.

• 3.2.3Consistent navigationAA

  Navigation that repeats across an agency’s interface stays in the same order. The same pattern is what residents recognize from one OPS agency to the next.

• 3.2.4Consistent identificationAA

  The same function keeps the same name. A tip, an alert, and a report are labeled the same way wherever they appear.

• 3.3.1Error identificationA

  If a form cannot be sent, the error is described in text and tied to the field that needs attention.

• 3.3.2Labels or instructionsA

  Fields have visible labels and instructions. The Title II assistance form tells the person what to correct before it can be sent.

• 3.3.3Error suggestionAA

  When the system knows how to fix an entry, such as a date or a required format, it suggests the correction in text.

• 3.3.4Error preventionAA

  Submissions that create a report or an assistance request can be checked before they are final. Incomplete required fields are stopped, and the browser describes what to fix.

• 4.1.1ParsingA

  Interfaces are delivered as standards-conforming HTML so assistive technologies can parse them. WCAG 2.1 still includes this criterion; valid markup is how OPS meets it.

• 4.1.2Name, role, valueA

  Controls expose their name, role, and state. OPS uses semantic HTML, and ARIA only where native HTML is not enough, so screen readers announce buttons, links, and fields correctly.

• 4.1.3Status messagesAA

  Confirmations, alerts, and form results are exposed to assistive technology. A status message is announced without forcing keyboard focus to jump when that is the right pattern.