Skip to main content
WebGlory
Menu

Services

Check your website across devices

Cross-browser and mobile testing

One page, every browser, every width

We open the pages you name on real handsets and on desktop browsers, and send back every place the layout gives way, with the steps to make it happen again.

Check your website across devices See a report in full
Down
Browser
Across
Screen width
In each cell
Home of example.test

A coral outline marks 6 of the cells. Each of them is written up further down, and every cell without an outline was looked at too.

360
390
412
810
1440
Chrome Blink
Safari WebKit
Firefox Gecko
Edge Blink
Samsung Internet Blink

Three axes

Pages across browsers across devices

The first screen shows one page against every browser and width. A run has a third axis: every page you name is looked at in every one of those pairings, and the same pairing is run both on hardware and in software where the two can disagree.

First axis

Pages

Agreed by address before anything starts, so what was covered is never a matter of opinion afterwards. A page that has several states - logged in, empty basket, form with errors showing - is listed as each of those states, because they are different pages as far as a layout is concerned.

Second axis

Browsers and widths

5 browsers across 5 widths, which is 25 pairings for a single page. Engines are named beside each browser on the coverage page: two browsers on one engine rarely disagree, and knowing that is worth more to you than a longer list.

Third axis

Real devices and emulation

8 devices somebody picks up, and 5 profiles driven on a desktop machine. Every finding says which of the two it came from, because a fault only hardware can show is a fault your own browser will never reproduce.

A run, page by page

Pages of the site in the run below, how many configurations each was looked at in, and how many findings came back from each.
Page Address Configurations Findings Highest priority
Home example.test/ 25 6 High
Category listing example.test/collections/outdoor 25 2 High
Product example.test/product/field-kettle 25 1 High
Basket example.test/basket 25 2 Medium
Whole run 4 pages 100 checks 11 5 of them high

Kept apart

A device is a device, and a profile is a profile

Emulation is a viewport, a pixel ratio and a user-agent string driven on a desktop browser. It finds layout and reflow faults quickly and cheaply, and there is a whole class of fault it cannot see at all.

Only hardware shows this

  • Software keyboards, and what they cover when they open over a field.
  • Touch behaviour proper: momentum scrolling, rubber-banding, double-tap zoom and the delay before a tap registers.
  • Screen cut-outs, rounded corners and the safe areas a browser reserves around them.
  • The browser interface itself appearing and disappearing as the page scrolls, and the viewport height changing while it does.
  • Fonts, colour handling and video decoding as the device itself does them.
  • How the page behaves on a slower processor than the machine running the emulation.

In the run below

8 of the 11 findings came off a device somebody held and 3 off a profile driven in software. Every card in the report names the one it came from, so nothing has to be taken on trust.

What is available

The devices and the profiles are listed by name, model by model. A run that says it covered a handset means somebody held that handset.

The full coverage list

What a run covers

Priced by pages and configurations

An order is described by its shape: how many pages, how many browsers, how many widths, and how much of it on hardware. The figure, the dates and the retesting it carries are settled for your site in a written quotation.

Spot Check

One path through a site: a landing page, a form and whatever it leads to.

Pages
3
Configurations
12
Checks in all
36
On hardware
2 devices
  • Each page opened and used at every width in the set, not only looked at.
  • Every finding written up with the steps to make it happen again and a screenshot of it in place.
  • Findings sorted by priority, so the order of work is decided before the report arrives.

Full Grid

The pages a visitor actually passes through: home, listings, a product or service page, a form, a basket or a booking step.

Pages
8
Configurations
25
Checks in all
200
On hardware
5 devices
  • Everything in Spot Check, across the full browser set.
  • The parts that only hardware shows: software keyboards over fields, safe areas, touch behaviour, the browser interface moving as the page scrolls.
  • A matrix of every page against every configuration, so what was looked at is as plain as what was found.

Every Page

A site that has to be covered end to end rather than sampled, page by page off an agreed list.

Pages
20
Configurations
25
Checks in all
500
On hardware
8 devices
  • Everything in Full Grid, over the whole list of pages agreed at the start.
  • Every device in the hardware list, so a fault tied to one handset is not missed by sampling.
  • A summary of what repeats across pages, which is usually one component rather than twenty separate faults.

A bigger site

A site with more pages than that is quoted on its own list of addresses. The shape is the same - pages against configurations - and the list is agreed in writing before anything is run.

What is not on this page

A figure, a number of working days and a number of retesting rounds. Those depend on what the pages turn out to be, and a number published before anybody has opened your site would be a guess dressed up as a commitment. They are in the quotation, in writing, before you accept anything. Prices are in pounds sterling, the quotation states one total with any tax already inside it, and nothing is added to it afterwards.

What comes back

The report, in full

Every finding from all 4 pages of the run, exactly as one arrives: priority first, then what class of fault it is, then where it was seen and on what, then how to make it happen again.

High priority 5

Something on the page cannot be read, reached or used at this size.

Medium priority 5

The page works, but it is harder to use or reads as broken.

Low priority 1

Worth putting right, and nothing is stopped by it.

F-01 High priority Sideways scroll

The cell this came out of, with the fault marked where it appears. The report itself carries a screenshot of it in place, taken on the machine named below.

The page can be dragged sideways by 28 pixels

Page
example.test/
Browser
Chrome (Blink)
Width
360 px
Device
Samsung Galaxy S22 Held in the hand

Steps to reproduce

  1. Open the home page on the Galaxy handset in Chrome.
  2. Scroll to the band of three promotional cards.
  3. Drag the page to the left.

Expected

Nothing moves. A page at this width has no second column to reveal.

Observed

The page slides 28 pixels and shows a strip of empty background. The third card keeps a left margin that is only cancelled at the tablet breakpoint, so at this width it pushes past the right edge and widens the document.

F-02 High priority Overlapping elements

The cell this came out of, with the fault marked where it appears. The report itself carries a screenshot of it in place, taken on the machine named below.

The fixed basket bar sits under the browser toolbar and cannot be pressed

Page
example.test/
Browser
Safari (WebKit)
Width
390 px
Device
iPhone 14 Held in the hand

Steps to reproduce

  1. Open the home page on the iPhone in Safari.
  2. Scroll down until the fixed basket bar appears.
  3. Try to press the button inside it.

Expected

The whole bar, and the button in it, stay above the browser interface.

Observed

The bar is positioned against the bottom of the viewport without allowing for the safe area, so the lower third of it, including most of the button, is behind Safari’s own toolbar. Presses in that region reach the browser rather than the page.

F-03 High priority Menu or button

The cell this came out of, with the fault marked where it appears. The report itself carries a screenshot of it in place, taken on the machine named below.

The menu opens with its close control off the screen

Page
example.test/
Browser
Samsung Internet (Blink)
Width
360 px
Device
Samsung Galaxy S22 Held in the hand

Steps to reproduce

  1. Open the home page on the Galaxy handset in Samsung Internet.
  2. Press the menu button.
  3. Look for the control that closes the panel again.

Expected

The close control is visible and reachable as soon as the panel opens.

Observed

The panel is wider than the viewport at this width, so the cross in its top right corner is outside the screen. The panel does not close on the browser back gesture either, and the only way out is to reload the page.

F-04 Medium priority Cut-off text

The cell this came out of, with the fault marked where it appears. The report itself carries a screenshot of it in place, taken on the machine named below.

Card titles are cut after one line and the rest cannot be read

Page
example.test/
Browser
Firefox (Gecko)
Width
412 px
Device
Google Pixel 7a Held in the hand

Steps to reproduce

  1. Open the home page on the Pixel in Firefox.
  2. Read the titles of the three cards in the middle band.

Expected

A title of any length is readable, in full, however many lines it takes.

Observed

The card has a fixed height with its overflow hidden, and at this width the titles run to two lines. The second line is cut off halfway down the letters, which reads as a rendering fault rather than as a design that ran out of room.

F-05 Medium priority Menu or button

The cell this came out of, with the fault marked where it appears. The report itself carries a screenshot of it in place, taken on the machine named below.

A drop-down that only opens on hover cannot be opened by touch

Page
example.test/
Browser
Safari (WebKit)
Width
810 px
Device
iPad (9th generation) Held in the hand

Steps to reproduce

  1. Open the home page on the iPad in Safari.
  2. Tap the navigation item that has a drop-down under it.

Expected

The drop-down opens on the first tap, and the item itself is not followed.

Observed

The first tap follows the parent link instead of opening the drop-down, so the items under it are unreachable on this device. The submenu is shown by a hover rule with no equivalent for touch or for the keyboard.

F-06 Medium priority Menu or button

The cell this came out of, with the fault marked where it appears. The report itself carries a screenshot of it in place, taken on the machine named below.

The last navigation drop-down opens past the right edge of the window

Page
example.test/
Browser
Edge (Blink)
Width
1440 px
Profile
Desktop profile Driven in software

Steps to reproduce

  1. Open the home page at 1440 CSS pixels wide.
  2. Open the drop-down under the last item in the navigation.

Expected

The panel stays inside the window, flipping to the left of its item if it has to.

Observed

The panel is anchored to the left edge of its item and has a fixed width, so at this width its right-hand half is outside the window. The window gains a horizontal scrollbar while it is open, and two of the items in it cannot be reached at all.

F-07 High priority Overlapping elements

The cell this came out of, with the fault marked where it appears. The report itself carries a screenshot of it in place, taken on the machine named below.

The filter panel opens over the results and will not close

Page
example.test/collections/outdoor
Browser
Chrome (Blink)
Width
810 px
Profile
Tablet profile Driven in software

Steps to reproduce

  1. Open the category listing at 810 CSS pixels wide.
  2. Press Filters.
  3. Press anywhere outside the panel, then press Escape.

Expected

The panel closes on a press outside it and on Escape.

Observed

The panel is drawn over the results with no way out at this width: the close control is only rendered below the tablet breakpoint, a press outside does nothing, and Escape is not handled. The results underneath cannot be scrolled while it is open.

F-08 Medium priority Cut-off text

The cell this came out of, with the fault marked where it appears. The report itself carries a screenshot of it in place, taken on the machine named below.

Filter labels are cut in the middle of a word

Page
example.test/collections/outdoor
Browser
Firefox (Gecko)
Width
412 px
Device
Google Pixel 7a Held in the hand

Steps to reproduce

  1. Open the category listing on the Pixel in Firefox.
  2. Open the filter list and read the labels.

Expected

A label either fits, wraps, or ends in an ellipsis that says it has been shortened.

Observed

Labels are held on one line and clipped at the edge of the control, so the longer ones end mid-word with nothing to show they continue. Two of the filters cannot be told apart from their visible text.

F-09 High priority Sideways scroll

The cell this came out of, with the fault marked where it appears. The report itself carries a screenshot of it in place, taken on the machine named below.

The image gallery drags the whole page sideways

Page
example.test/product/field-kettle
Browser
Safari (WebKit)
Width
390 px
Device
iPhone 14 Held in the hand

Steps to reproduce

  1. Open a product page on the iPhone in Safari.
  2. Swipe across the image gallery.

Expected

The gallery moves on its own and the page behind it stays still.

Observed

The gallery is a horizontal scroller without its overscroll contained, so a swipe past the last image carries the page with it. The header slides out of view and the page stays offset until it is reloaded.

F-10 Medium priority Overlapping elements

The cell this came out of, with the fault marked where it appears. The report itself carries a screenshot of it in place, taken on the machine named below.

The discount field is covered by the order summary

Page
example.test/basket
Browser
Edge (Blink)
Width
1440 px
Profile
Desktop profile Driven in software

Steps to reproduce

  1. Open the basket at 1440 CSS pixels wide with two items in it.
  2. Scroll to the foot of the basket.

Expected

The summary sticks beside the basket without covering anything in it.

Observed

The summary is positioned absolutely against the page rather than inside its own column, and at this width it lands on top of the discount field. The field can still be reached with the keyboard, but it cannot be seen or pressed.

F-11 Low priority Press target

The cell this came out of, with the fault marked where it appears. The report itself carries a screenshot of it in place, taken on the machine named below.

The quantity controls are too small to hit reliably

Page
example.test/basket
Browser
Samsung Internet (Blink)
Width
360 px
Device
Samsung Galaxy S22 Held in the hand

Steps to reproduce

  1. Open the basket on the Galaxy handset in Samsung Internet.
  2. Change the quantity of an item using the plus and minus controls.

Expected

Each control is comfortably bigger than a fingertip, with space around it.

Observed

The two controls are 24 by 24 pixels and sit next to each other with no gap, so a press often lands on the wrong one. The item is removed rather than reduced when the count is already at one.

After a fix

Retesting is part of the order, not a favour

A report that is never checked again is half a job. The conditions are the same for every order; how many rounds one carries depends on the size of the site and on how you are releasing the work, so it is settled in the quotation.

What a retest looks at

The findings you say you have fixed, on the pages they were found on, in the configurations they were found in. Not the whole run again: a fault reported on one handset is confirmed on that handset.

What comes back

The same report with each retested finding marked as gone, still present, or changed. A finding that has moved rather than gone is written up again, because at that point it is a different fault.

When it happens

On a date agreed when you tell us the fixes are live. Every order names its retesting window and how many rounds it carries in the written quotation, because that depends on the size of the site and on how the work is being released.

What counts as new work

A page that has changed beyond the fixes, a configuration that was not in the original run, or a finding raised after a redesign. Those are quoted before anything is run, never added to an invoice afterwards.

How it works

How a list of pages becomes a grid of results

Six steps, and two of them are yours. Nothing runs before the scope and the authorisation are in writing.

  1. 01

    You send the addresses

    The pages you want looked at, by address, and the browsers, widths and devices that matter to you. If you are not sure which those are, say who your visitors are and we will propose a set and put it in writing before anything runs.

  2. 02

    You confirm you may have it tested

    A short written confirmation that the site is yours, or that the owner has asked you to submit it. Nothing is run until it is in writing: testing somebody else’s site without it is not something a report can put right afterwards.

  3. 03

    A quotation, in writing

    The list of pages, the list of configurations, the price in pounds sterling with any tax already inside it, the dates, and the retesting the order carries. Nothing is added to the figure afterwards, and no work starts before you have accepted it.

  4. 04

    The run

    Each page is opened and used at each width, on the hardware the order names and on the profiles for the rest. Faults are photographed where they happen and written up as they are found.

  5. 05

    The report

    A matrix showing what was looked at, and a finding for every fault: priority, class, page, browser, width, device, steps to reproduce, expected and observed, with a screenshot of each.

  6. 06

    The retest

    When you say the fixes are live, the findings you have fixed are checked again, on the pages and in the configurations they were found in, and the report comes back marked.

Check your website across devices

Send the addresses, the pages that matter and the devices you care about. A written quotation comes back with the scope, the figure and the dates on it, and nothing runs until you have accepted it.

Start a request What a report contains