Accessibility statement

Bottle is used by people standing in a yard in the rain, by people at a desk all day, and by people who need a screen reader, larger text or a keyboard to get their work done. This page says what we have built for that, how we tested it, and where we know we are still short.

What this covers

Three things: the website you are reading now at getbottle.app, the Bottle software that a gas business signs in to at my.getbottle.app, and the driver apps for iPhone and Android. They are separate pieces of software and have been tested to different depths, so each is described separately below rather than lumped together.

The standard we measure against

We aim at the Web Content Accessibility Guidelines version 2.2, level AA. That is the level referred to by most public sector and procurement rules in the United Kingdom, and it is the level we hold our own tests to.

We believe the Bottle software and this website meet that standard on the screens we have tested, and our tests fail the build if they stop meeting it. We are not claiming we meet it everywhere, because we have not tested every screen, and we say which below. There has been no external audit and no certification, so nothing on this page is a third party's opinion. It is ours, with the working shown.

What works in the Bottle software

This is the part a gas business signs in to at my.getbottle.app, used on a computer or a tablet.

• The whole thing works from a keyboard. Every action can be reached and carried out without a mouse, and the focus outline is always visible so you can see where you are. Stops on a round can be reordered with Move up and Move down buttons rather than only by dragging, because dragging is the sort of thing that quietly excludes people.
• A skip link. The first thing a keyboard or screen reader reaches on every page is a link straight to the main content, so you are not walked through the menu again on every page.
• Headings and landmarks are real. Each page has one main heading, headings go in order without skipping levels, and the header, navigation and main content are marked up as such, so a screen reader can jump between them.
• Fields have labels, and errors are attached to the field they belong to rather than floating somewhere else on the page, so a screen reader reads the field and its problem together.
• Light and dark, and a choice. An appearance button sits next to your account menu with three options: follow your computer, always light, or always dark. The choice is remembered and the correct one is drawn before the page appears, so there is no flash of the wrong one.
• Text contrast is enforced by a test. Every colour pairing the software draws is checked to 4.5:1 for text and 3:1 for the outline of a control, in both light and dark. If somebody changes a colour and breaks that, the build fails before it can reach you.
• It works on a small screen. Pages are tested at 320 pixels wide, which is a small phone, with no sideways scrolling.
• Reduced motion is honoured. If your computer is set to reduce motion, every animation and transition in Bottle stops. Not most of them.

What works in the driver apps

These are the apps a driver uses on an iPhone or an Android phone, out on a round.

• VoiceOver on iPhone and TalkBack on Android. Each drop on the round is a single item with its own actions, so a driver can navigate to it, mark it delivered or say it could not be delivered without hunting for buttons. Headings are marked as headings, and the state of something is described rather than only shown.
• Text grows with your phone's setting. Both apps use the system text size rather than fixed sizes, and layouts stack instead of squashing when the text gets large. Nothing has a fixed height that would cut words off.
• A real dark theme on both, following the phone's own setting rather than a separate switch to find.
• Reduced animation. If the phone is set to reduce motion, cards fade in rather than sliding, and the microphone button stops pulsing.
• Touch targets are at least 48 by 48. Buttons are big enough to hit with a gloved hand or an unsteady one, which is the same thing that helps somebody with a tremor.
• You can speak the name of whoever signed instead of typing it, on both phones, which helps if typing on a small keyboard is difficult.

What works on this website

The website you are reading now is a small set of pages with no sign-in. It works from a keyboard, has one main heading per page with headings in order, marks up its header, navigation and main content properly, meets the 4.5:1 contrast level for text, and works at 320 pixels wide without sideways scrolling. The two typefaces are served from this website rather than from another company, so no request leaves your browser when you read these pages.

How we tested it

We have used automated accessibility testing, which is built into the tests that run before anything is released. Here is the scale of it, so you can judge it rather than take a word like "thorough" on trust.

• The Bottle software, in a real browser. Thirteen screens, including signing in, the day's overview, orders, customers, rounds, invoices, stock, products, people, security settings, business settings and billing. Each one is checked with axe, an accessibility testing tool, in both light and dark appearance, at desktop width and again at 320 pixels. That is twenty six checks on every release.
• The Bottle software, screen by screen. Thirteen further accessibility checks run against individual parts of the software as they are built, including the sign-in screens, the customer, order, invoice and round lists, the console our own staff use, the password and notification settings, the appearance button and the pop-up dialogs.
• Colour contrast. Eighty checks on every release, covering forty colour pairings in each of the light and dark appearances. These fail the build rather than producing a warning somebody can ignore.
• The iPhone app. Thirty six tests run against the app on a simulated iPhone, and seven of them run Apple's own accessibility audit over whatever is on screen at that moment, covering signing in, loading the van, a drop that is not ready to save, the next drop card and the account sheet. Apple's audit checks contrast, text that does not grow, elements a screen reader cannot read and buttons too small to hit.
• The Android app. Thirty seven tests run against the app on a simulated phone, six of which have Google's accessibility checks switched on, covering the same ground. A further test checks that every text colour in the app meets 4.5:1 in both light and dark.
• This website. Checked with the same axe tool at desktop and phone width, by hand rather than as part of an automatic test suite, because this site has no test suite of its own.

Where we know we are short

This is the honest part, and we would rather write it down than have you discover it.

Nobody who relies on assistive technology has tested Bottle. Everything above was found by automated tools and by people who do not use a screen reader daily. Automated testing catches somewhere around a third of real accessibility problems, and it is particularly poor at judging whether something makes sense when read aloud, as opposed to whether it has a label at all. This is the biggest gap on this page, and no amount of passing tests closes it. If you or one of your drivers uses a screen reader and would be willing to tell us what is wrong, we would genuinely like to hear from you.

We have tested narrow screens rather than zoomed text. The standard asks that text can be enlarged to 200 per cent without losing content or function. We test that pages work at 320 pixels wide, which exercises much of the same reflow, but it is not the same test, and we have not yet checked 200 per cent zoom directly.

Recording a delivery needs a finger or a pointer. When a driver records a delivery, the two ways of proving it are a signature drawn on the screen and a photograph of where the cylinder was left. Both need a touchscreen or a mouse, and neither can be done from a keyboard alone. We do not have a good answer for this yet. It is a real limitation for anyone who cannot use a pointer, and it is on our list.

Maps are maps. Planning a round and tracking a van both show a map. The same information is available in the list beside it, and every action on a round can be carried out from that list, so the map is not the only route to the work. But a map is a visual thing and we have not made the map itself readable by a screen reader.

Not every screen is covered by the automated checks. The thirteen screens listed above are the main ones. The setup steps a new business goes through, the driver's own screens inside the web app, and the public delivery tracking page are not in that automatic sweep, although they were checked by hand during the work. We intend to bring them into the standing tests.

The driver apps have been checked by Apple's and Google's automated audits, not by a person using a screen reader. Those audits are good at catching contrast, size and missing labels. They cannot tell you whether the order things are read in makes sense to somebody driving a van.

Telling us about a problem

If something in Bottle does not work for you, email privacy@getbottle.app and tell us what you were trying to do, what happened, and what you use to get around the screen if you would rather say. A person reads that address.

We will reply within five working days. If it is something we can fix quickly we will tell you when it is fixed. If it is something that will take longer, we will tell you that honestly rather than leaving you waiting, and we will say what we are doing about it.

What we are doing next

Three things are planned rather than aspirational. We will test text zoomed to 200 per cent directly rather than inferring it from narrow screens. We will bring the setup steps, the driver screens and the tracking page into the automatic accessibility checks that run on every release. And we are looking for a way to record a delivery that does not need a pointer.

How this page is kept honest

Every number on this page comes from a test that runs on our own code, and we checked each one on the day this page was written rather than repeating what we said last time. If a claim here stops being true, the test that backs it fails first. We will review this page whenever the software changes in a way that affects it, and in any case by 28 March 2027.