Accessibility at EcoGrant

We are committed to making EcoGrant usable by everyone. Our goal is to design inclusive, keyboard accessible and screen reader friendly experiences so people of all abilities can discover programs, complete applications, and stay informed.

Last updated:

Our commitment

  • Meet or exceed WCAG 2.2 Level AA for new and updated content.
  • Use semantic HTML, visible focus states, and sufficient color contrast across the interface.
  • Provide full keyboard navigation and screen reader compatibility for critical journeys.
  • Avoid color only cues and provide alternatives for motion and time limited tasks.

Conformance status

We target WCAG 2.2 Level AA conformance. Some legacy content may not fully meet standards. These items are tracked and prioritized alongside feature work. Third party embeds such as maps and video players may have their own accessibility limits that we work to mitigate.

Primary scope. Public site content, program discovery, and application forms.

Partial exclusions. Third party widgets and embeds.

Supported technologies

  • Browsers: Latest two versions of Chrome, Firefox, Safari, and Edge.
  • Operating systems: Current macOS, Windows, iOS, and Android.
  • Assistive technologies: VoiceOver on macOS and iOS, TalkBack on Android, NVDA and JAWS on Windows.

Older browsers or operating systems may still work but are not part of our formal test matrix.

How we build for accessibility

  • Design system: components include contrast checks, focus indicators, and ARIA semantics.
  • Keyboard support: all interactive elements are tabbable and operable with Enter or Space.
  • Structure and landmarks: logical headings, ARIA landmarks, and descriptive labels.
  • Forms: labels for every input, clear error messages, and instructions that do not rely on color alone.
  • Media: images include alt text when needed and empty alt when decorative. Video includes captions and transcripts when available.
  • Motion and flashing: we respect reduced motion preferences and avoid flashing content.
  • Performance: fast pages improve access for users on assistive technology and low bandwidth connections.

Ongoing testing

  • Automated: linting and continuous integration checks for common issues.
  • Manual: keyboard walkthroughs and screen reader smoke tests for critical flows.
  • Audits: periodic expert reviews to catch regressions and gaps.
  • Telemetry: performance and error monitoring to identify barriers.

Plain language

We write for clarity. We use common words, short sentences, and direct calls to action. We avoid jargon when possible and explain required terms in simple words.

  • Headings describe the content that follows.
  • Each paragraph focuses on one idea.
  • Examples are provided when instructions could be read in more than one way.

Keyboard navigation and focus

Every interactive control can be reached and used with a keyboard. Focus order follows the visual layout and the focus indicator remains visible at all times.

  • Tab order follows the reading order.
  • Enter and Space activate buttons and controls.
  • Escape closes dialogs and menus.

Color and contrast

Text and important icons meet recommended contrast. Information is never conveyed by color alone. We provide additional cues such as labels and patterns.

Language support

Some information is available in multiple languages. When translation is not available, users can request help and we will provide support.

Usability research

We invite people with a wide range of abilities to provide feedback on prototypes and live features. Findings inform our roadmap and improvements.

  • Short research sessions with task based reviews.
  • Remote observation with consent.
  • Follow up summaries that guide design updates.

Error prevention and recovery

  • Clear labels and helpful hints before input.
  • Validation that explains what went wrong and how to fix it.
  • Undo where possible and confirm before permanent actions.

Related policies and notes

  • Nondiscrimination. We do not discriminate on the basis of disability and we provide reasonable accommodations on request.
  • Language assistance. Some content is available in more than one language. Contact us if you need help in another language.
  • Third party services. We integrate tools such as maps, video, and analytics that we do not fully control. We select accessible vendors and raise issues when found.
  • Compatibility. Assistive technologies and browsers may render content differently. If your setup has trouble, tell us and we will investigate.
  • VPAT. A voluntary product accessibility template or similar documentation can be provided to partners upon request.

Support for accessibility

We provide multiple ways to reach our team. If you need another format or a different way to contact us, tell us and we will meet your needs.

  • Response target for accessibility requests is five business days.
  • Urgent issues are escalated to the product team.

Continuous improvement

Accessibility is an ongoing effort. We review feedback, monitor metrics, and invest in training so that accessibility remains a core quality bar and not a one time project.