BuyLow

Accessibility

What we build towards, what is already in the product, and how to tell us when something does not work for you.

Last updated 29 September 20266 sections

3 parts of this document need review before it is final

Everything else here describes how BuyLow works today, checked against the running product. The parts marked Needs review cover decisions that have not been made yet. The operating entity, governing law, liability limits, tax handling, a contact address. They are listed so you can see them, not filled in with plausible-sounding text that nobody has agreed to.

1.Our commitment

BuyLow should be usable by everyone, including people who browse with a keyboard only, use a screen reader, need larger text, or have a visual, motor or cognitive difference. We treat accessibility as a requirement of the product rather than a setting that can be turned off.

2.The standard we work to

We design and test towards WCAG 2.2 at Level AA. That is the standard most public-facing sites are held to in the US (Section 508) and the EU (EN 301 549, which adopts WCAG).

A conformance claim is only worth making with a tested statement behind it, so we have not published one.

Needs review

  • An accessibility conformance report stating the level assessed, the date of the audit, and the known issues — none has been carried out yet.
  • Whether a named accessibility contact is required in the jurisdictions BuyLow operates in.

3.What is already in the product

These are properties of the code as it stands, not intentions:

  • Every page is laid out to work on a 390px-wide phone as well as a 1440px-wide desktop, with no sideways scrolling; wide tables scroll inside their own container instead of moving the page.
  • Dropdowns are custom-built, not native select elements, and are fully operable from the keyboard, with the expanded state announced to a screen reader.
  • Every interactive control has a visible focus ring, and form errors are written next to the field, not only in a summary.
  • Form fields have real labels, and buttons and links have accessible names, so they can be found by their role and their name.
  • Status is never shown by colour alone: order states and badges carry a word as well as a colour.
  • Product images carry alt text, and images that are still loading reserve their space so the page does not jump.
  • The site is served over HTTPS, and the page is marked up with a language so a screen reader uses the right voice.

4.Known limitations

No independent audit has been carried out, so we cannot claim the site conforms. The gaps we already know about:

  • The sales chart and sparklines on the seller dashboard are drawings, and are described to a screen reader as a summary rather than being navigable point by point.
  • The image uploader in the seller area does not yet announce upload progress to a screen reader while a file is being sent.
  • Motion is not yet reduced automatically for people whose operating system asks for reduced motion.
  • The seller area's dense tables are readable by keyboard but are a long way from being ideal with a screen reader.

Needs review

  • A schedule for an independent WCAG 2.2 AA audit, and a public conformance report to go with it.
  • A documented process for triage and turnaround on an accessibility report, with a target response time.

5.Feedback and assistance

If a page does not work for you, we want to know which page, what you were trying to do, and what happened. A report that names the page and the problem is the most useful thing you can send us.

Needs review

  • The email address for accessibility reports — it has not been set up yet, and the transactional sender address is not monitored.
  • A response time commitment for an accessibility report.

6.Ongoing improvements

Accessibility is checked when a page is built, not after it ships. Any page we redesign is rebuilt to the current standard rather than being patched, and the known limitations above are removed in the order they affect the most people.