Accessibility-Focused Design for Software Everyone Can Use
Interface design and review work that makes your software usable with a keyboard, a screen reader, weak eyesight, colour blindness or an unsteady hand. GullySystem designs against the WCAG success criteria and reports what still needs fixing.
Who Accessibility Design Is Actually For
Accessibility is usually explained as a service to a small group of users. In practice it covers a much wider set of ordinary situations: a supervisor reading a phone in direct sunlight, a proprietor who has not updated his glasses in years, a data entry operator who works entirely by keyboard because the mouse is slower, a customer on a bus with one hand on the rail. Designing for the hardest case improves the screen for all of them.
- Accessible design for new screens, and accessibility review of software you already run
- Covers colour and contrast, keyboard operation, screen reader labelling, forms, error messages and zoom behaviour
- Relevant to public-facing portals, education and healthcare software, and anything the general public has to use unaided
- Delivered as designs and a written findings list against the criteria, not as a compliance certificate
The Barriers We Find Most Often
Most accessibility problems are ordinary design habits rather than exotic technical faults. These come up again and again.
Light Grey Text on White
Pale text looks refined on a designer's monitor and disappears on a phone outdoors or on an older office screen. It is among the most common problems we find, and among the cheapest to fix.
Colour as the Only Signal
Red rows for overdue and green for cleared, with nothing else separating them. To a colour-blind user, and on any printed copy, the two rows are identical.
Screens That Cannot Be Operated by Keyboard
Custom dropdowns, date pickers and dialogs that respond only to a mouse. A keyboard user reaches them and stops, and so does anybody using assistive technology.
Fields With No Real Label
A form whose labels exist only as grey placeholder text inside the box. The label vanishes the moment typing starts, and a screen reader announces an unnamed field.
Errors Shown Only in Colour
A red border and nothing else. The user knows something is wrong somewhere on the form, but not what it is and not what would satisfy it.
Icon-Only Buttons With No Name
A row of small icons carrying meaning that exists only in the picture. Nothing is announced, nothing appears on a printout, and new staff guess by clicking.
How Accessibility Is Built Into the Design
Decided during design, most of this costs nothing extra. Decided after the build, each item becomes a change request with a price on it.
Contrast Decided at the Palette Stage
Colour pairings are checked against the contrast ratios when the palette is chosen, so the question is settled once instead of being argued screen by screen during the build.
Every Signal Carries a Second Cue
Status is shown by colour and by a label, an icon or a pattern, so the meaning survives colour blindness, a greyscale print and a dim screen in a warehouse.
A Visible Focus Order
We specify the tab order for each screen and design a focus indicator that can genuinely be seen, so a keyboard user always knows where they are standing.
Names for Things That Have None
Icon buttons, form fields, tables and page regions are given the text assistive technology reads out, written during design rather than guessed at during the build.
Errors Explained in Words
Validation messages sit beside the field, say what is wrong and what would fix it, and are announced rather than only coloured.
Layouts That Survive Zoom
Screens are designed to hold together when text is enlarged or the browser is zoomed, with content reflowing instead of overlapping, clipping or vanishing off the edge.
Reviewing Software You Already Run
Where the software exists, the work starts with a review rather than a redesign.
A Keyboard and Screen Reader Walkthrough
We work through the journeys that matter most using only a keyboard, and again with a screen reader, and record exactly where a user would be stopped.
Contrast Audit of Your Palette
Every colour pairing in your existing screens is measured, with replacement values supplied for the ones that fail so your developers have a decision, not a complaint.
Findings Written Against the Criteria
Each issue is tied to the screen it appears on and to the success criterion it fails, so the list can be handed straight to a developer or attached to a procurement response.
Blockers Separated From Improvements
Issues are split into what stops somebody completing a task, what makes it painful, and what would simply be better, so a small team knows where to begin.
Redrawn Screens Where Design Must Change
Some fixes are code changes and some need a design decision. The second kind come back as redrawn screens rather than as instructions.
Notes Written for Developers
Labels, states, focus behaviour and announcement text specified per component, so the fix does not depend on somebody interpreting a guideline correctly.
How Far the Accessibility Work Reaches
This work can be a review of three journeys or a pass across an entire product. The boundary is set before anyone starts.
New Design or Existing Software
Building accessibility into screens being designed anyway adds modest effort. Retrofitting a product built without it means reworking components that dozens of screens depend on.
How Much of the Product Is in Scope
Reviewing the three journeys that matter most is a contained piece of work. A full audit across every screen in a mature product is not, and we would rather do the first well.
The Standard You Are Aiming At
Which WCAG level you are working towards changes what has to be met. We agree the target at the start and report against it, item by item, so there is no ambiguity later.
How Custom the Components Are
Screens built from standard form elements start close to accessible. Screens built from hand-coded dropdowns, grids and dialogs need far more work before they behave.
Whether Assistive Technology Testing Is Included
Checking designs against the criteria is one piece of work. Running the built screens with a screen reader, and with people who depend on one, is a further step and is scoped on its own.
Where Accessibility Work Connects
Accessibility is easiest and cheapest when it is decided during design rather than added afterwards. That work sits inside the wider service.
Frequently asked questions
Is accessibility a legal requirement for our software?
It depends on who you sell to and where, and we are not lawyers, so treat this as practical rather than legal guidance. Government and large enterprise procurement often asks accessibility questions, and organisations serving the public are asked more often than those selling internally. What we provide is design against the WCAG success criteria and a written record of what was met and what was not, which is usually what those conversations need.
Can you certify that our software is accessible?
No, and be careful of anyone who offers to from a design engagement alone. A conformance claim rests on testing the built product, not the design files, and it is made by the organisation that owns the product. What we give you is designs that meet the criteria and a documented review of the built screens against them.
Will accessible design make our interface look plain?
No. Almost all of this is invisible: contrast values, a second cue beside colour, focus order, field labels, message wording. The parts a visitor notices are readable text and clear buttons, which people prefer anyway. Where a design choice genuinely conflicts with a criterion, we show you both options and the trade-off rather than deciding quietly.
What drives the cost of accessibility work?
Whether it is design or retrofit is the biggest factor. Building it into new screens is a portion of the design effort. Fixing an existing product depends on how many screens are in scope, how many custom-coded components they use, and whether testing with assistive technology and real users is included.
How long does an accessibility review of an existing product take?
It follows the number of journeys in scope more than the size of the product. A review of the main paths through a portal is quick to run and report; a screen-by-screen audit of a mature product with many custom components takes considerably longer. We agree the journey list first so the timeline is based on something real.
Can our own developers act on the findings without you?
Yes, and the report is written for that. Each item names the screen, the problem, the criterion it fails and what the fix should be, including the exact labels and states a component needs. You own the findings and the redrawn screens outright, and we are available for review when the fixes are built rather than required for them.
What do you need in order to review our existing software?
A test login with data we may change, a list of the journeys that matter most to your users, the browsers and devices your users are on, and anybody in your organisation who already uses assistive technology and is willing to spend half an hour with us. Screenshots alone are not enough, because most of these problems only appear when the screen is operated.
Tell us what you need.
Send a short brief and one of our engineers will come back to you — usually the same day.
- No obligation
- We reply the same working day
- Your details stay private