Service
Cross-Browser Testing
The same markup, the same stylesheet, five browsers on three engines. Most of the time they agree. The work is finding the places where they do not, before somebody you were hoping to sell to finds them instead.
What is done
What the work actually consists of
Every agreed page at every width
Each page on the list is opened at each width in the set, in each browser in the set, and scrolled from top to bottom. Not a screenshot taken and glanced at: the page is used.
Interaction, not only layout
Menus are opened and closed, forms are filled in and submitted with bad input as well as good, anything that expands is expanded, anything sticky is scrolled past, and anything that hides behind a breakpoint is looked for at the width where it should appear.
The awkward widths, on purpose
A layout is usually sound in the middle of a breakpoint and fragile at its edges. Pages are checked at the width where a rule takes over, which is where a navigation bar appears before it fits and a three-column row becomes two.
Keyboard and focus, as far as layout goes
Whether the focus outline is visible on each browser, whether it survives a coloured background, and whether the tab order still follows the page once a layout has reflowed. This is not a full accessibility audit and the report says so.
What you get back
- A matrix of every page against every configuration, so what was covered is as plain as what was found.
- A finding for each fault: priority, class, page, browser, width, steps to reproduce, expected and observed.
- A screenshot of each fault in place, at the width it appeared at.
- A note where a fault repeats across pages, because that is usually one component rather than many faults.
What is not in it
- Fixing the code. Findings are written so a developer can act on them; the fixing is a separate piece of work and is quoted separately.
- Browsers or versions outside the set agreed in the quotation.
- Load testing, security testing or a full WCAG audit.
Saying what is not included is not modesty. A buyer who expects one of these and does not get it has bought the wrong thing, and that is the disagreement worth preventing before an order rather than after it.
One page, close up
What a browser set looks like when it is all on one screen
The same page in every pairing. The cells outlined in coral are the ones with something in them; the rest were looked at and had nothing to report, which is a result and not an absence of one.
-
F-01 Sideways scroll
The page can be dragged sideways by 28 pixels
Chrome at 360 px
-
F-02 Overlapping elements
The fixed basket bar sits under the browser toolbar and cannot be pressed
Safari at 390 px
-
F-03 Menu or button
The menu opens with its close control off the screen
Samsung Internet at 360 px
-
F-04 Cut-off text
Card titles are cut after one line and the rest cannot be read
Firefox at 412 px
-
F-05 Menu or button
A drop-down that only opens on hover cannot be opened by touch
Safari at 810 px
-
F-06 Menu or button
The last navigation drop-down opens past the right edge of the window
Edge at 1440 px
Each of those is written up in full on the home page report, with the steps, the expected behaviour and what happened instead.
Check your website across devices
Send the addresses and the devices that matter to you. The scope, the figure in pounds sterling and the dates come back in writing, and nothing runs until you have accepted them.
The other two
Mobile and Device Testing
Opening agreed pages on physical handsets and tablets, and on emulated profiles, with every finding marked according to which of the two it came from.
Reports and Retesting
Writing every fault up so it can be reproduced and prioritised, and checking the fixes afterwards on the pages and in the configurations the faults were found in.