About

Accessibility

Accented adds its own UI elements to the host application. For each element with accessibility issues, it inserts a button that opens a dialog describing the issue.

We aim to make those elements as accessible as possible.

• They can be navigated using only the keyboard.
• They use appropriate semantic HTML.
• Interactive elements, such as links and buttons, have meaningful accessible names.
• The language of Accented’s UI (currently English) is correctly specified for assistive technologies.
• Color combinations have sufficient contrast.
• Interactive elements are large enough for touch navigation, and all content remains accessible without relying on hover.
• Content can be resized without requiring horizontal scrolling.
• Font sizes scale with browser settings (defined using em / rem units).

Accented follows WCAG 2.2 level AA as a baseline, and going beyond it by incorporating best practices and community feedback.

If you encounter an accessibility issue within Accented itself or have suggestions, please open an issue on GitHub or contact the maintainer directly at hello@pavelpomerantsev.com.

Browser support

Accented supports the two latest major versions of Chrome, Safari, and Firefox.

Safari is the only major browser where minor versions significantly differ in Web Platform support. Within each supported major version, Accented supports the two latest minor versions. For example, if 18.5 is the latest version, Accented will support 17.5, 17.6, 18.4, and 18.5.

Before each release, Accented’s Playwright test suite runs in the latest versions of Chrome, Safari, and Firefox.

Maintainers may remove fallback code for modern browser features once those features are fully supported in all supported browsers. We assume that most developers keep their development browsers up to date. However, when browser updates are tied to OS updates (as with Safari), staying current may be harder. That’s why we support Safari versions that may be over a year old.

Versioning

Accented follows Semantic Versioning (SemVer).

In practice, here’s how we decide whether a release should be major, minor, or patch.

Major:

• A breaking API change.

Minor:

• A non-breaking (additive) API change.
• A behavioral change that isn’t a bug fix (for example, when Accented starts reporting a new class of issues).

Patch:

• A bug fix.
• A performance improvement.
• A non-breaking UI improvement.
• A runtime or build-time dependency update (for example, upgrading TypeScript, which may affect build output).
• A README fix that’s visible on the NPM package page.

No version change:

• Dev/test-only dependency updates (for example, JSDOM).