Accessibility Statement

Our Commitment

TickerPosts is built to be usable by as many people as possible, including visitors who rely on screen readers, voice control, keyboard navigation, screen magnification, reduced motion, or high-contrast settings. Accessibility is treated as part of how the site is built, not as a separate project. Every new page and component is checked against the same standards described below before it ships.

Standard We Aim For

TickerPosts targets conformance with the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA. That is the same level required by the European Accessibility Act and by EN 301 549, the harmonised European standard for accessible digital services. Level AA is also the conformance level most public-sector accessibility laws in the United States and the United Kingdom use as a reference. We aim to meet WCAG 2.1 AA on every page that is reachable without signing in, and on the signed-in surfaces (watchlist, comment composer, account settings) too.

What We Have Done So Far

The features below are in place across the site today. They are listed so you know what to expect, and so a reader using assistive technology can see in advance how the site behaves.

A "Skip to main content" link is the first focusable element on every page, so keyboard and screen-reader users can move past the header navigation without tabbing through every link.
Pages use semantic HTML (headings in order, real lists, real buttons, real landmarks). The header, main content area, and footer are exposed as landmarks, and the footer link group is its own labelled navigation landmark for direct screen-reader access.
Page zoom is not locked. You can pinch-zoom on a phone or use browser zoom on desktop. Form inputs use a font size that does not trigger automatic zoom on iOS Safari.
The site supports light and dark themes, and follows your system preference by default. Theme choice is remembered between visits.
Animations and transitions respect the prefers-reduced-motion setting in your operating system or browser. If you have that setting on, non-essential motion is suppressed.
Interactive elements have a visible focus outline when you reach them with the keyboard, so it is clear where you are on the page.
Decorative separators (such as the middle dots between footer links) are hidden from assistive technology so the link list is not read out as a string of dots between names.
Images that carry information have descriptive alternative text. Images that are purely decorative are marked as such so screen readers do not announce them.
Form labels are connected to their fields, and important status messages (sign-in errors, comment posting errors) are exposed to assistive technology rather than only shown visually.
The discussion and trust pages render their full content as plain HTML. You do not need JavaScript enabled to read articles, ticker overviews, comments, or the glossary.

Compatible Browsers And Assistive Technology

TickerPosts is designed to work with current versions of the major browsers (Chrome, Firefox, Safari, and Edge) on desktop, tablet, and mobile. Screen readers we test against include NVDA and JAWS on Windows, VoiceOver on macOS and iOS, and TalkBack on Android. The site is built to degrade gracefully on older browsers and on browsers with JavaScript disabled: layouts simplify, but the content remains readable.

Known Limitations

We want this statement to be honest, so the gaps we are still working on are listed here rather than left out. None of these prevents the core reading and discussion experience, but each one is on the list of things to improve.

The price chart on each ticker page is currently a visual element only. A screen-reader summary and a data-table alternative for the same numbers are planned. In the meantime, the high, low, and most recent prices are also shown as text next to the chart, and the same data is available in the ticker overview card.
We have not yet completed a full WCAG 2.1 AA audit pass with a dedicated accessibility tool, only the per-feature checks described above. A formal pass is on the roadmap.
Some smaller icon-only controls (vote arrows, copy-link icons) may be close to but not always above the recommended minimum tap-target size on the smallest phone screens. A target-size review is planned.
The discussion composer announces post errors visually and through a toast notification, but the announcement is not as verbose as a dedicated live region. Improving this is on the list.
Third-party content embedded on the site (for example, official filings or exchange data) may not meet the same standard as our own pages. Where we can substitute a plain-text or table-based view, we do.

How To Report An Accessibility Problem

If something on the site is hard or impossible to use with your assistive technology, we want to know. The fastest way to reach the team is the contact channel listed on the About page. Please include the page address, what you were trying to do, what happened instead, and the browser and assistive technology you were using (for example, "Safari with VoiceOver on iPhone" or "Firefox with NVDA on Windows"). That detail lets us reproduce the issue quickly.

We aim to acknowledge accessibility reports within a few business days and to either ship a fix or share a plan for one. Critical issues that block reading or posting are prioritised over polish items.

How Often This Statement Is Reviewed

We review this statement at least once per quarter, and any time a visible change to the site could affect accessibility. The date at the top of the page reflects the most recent review. When something substantive changes (a new known limitation is documented, a previous limitation is resolved, or the conformance target is updated), the change is also noted in the changelog.

For other policies that affect how the site is used, see the community guidelines, the editorial policy, the privacy policy, and the disclaimer.