E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 3 (In chronological order)

From: glen walker
Date: Fri, Apr 10 2020 11:50AM
Subject: browser size when testing resize text and text spacing
No previous message | Next message →

When testing for 1.4.4 resize text and 1.4.12 text spacing, is there a
"reasonable" browser size to test with? If I zoom the text to 200% or I
apply CSS to adjust the line height, letter spacing, etc, often times the
page looks good in what I consider (personally) a decent sized browser
window. But if I shrink the width of the browser, at some point, text
sometimes overlaps or is truncated.

1.4.10 sort of talks about a browser size (you can set the width to 1280
then zoom to 400% to effectively get 320 pixels) but the browser size isn't
mentioned with 1.4.4 or 1.4.12.

If 1.4.4 and 1.4.12 look good in a browser down to, say, 600 pixels wide,
but then text overlaps smaller than that, would you report it as a failure
but with a lower priority? But if overlaps happens at a larger size,
report it with a higher priority?

From: Steve Green
Date: Fri, Apr 10 2020 12:55PM
Subject: Re: browser size when testing resize text and text spacing
← Previous message | Next message →

I would report it, but it is not the tester's role to tell people what the priority should be - their role is to provide information, such as the impact of non-compliances and possible solutions. Prioritisation is the responsibility of the product owner, who needs to take into account other factors such as the cost and time required for fixes, technical and legal risks, resource availability etc.

Steve Green
Managing Director
Test Partners Ltd

From: Patrick H. Lauke
Date: Fri, Apr 10 2020 1:07PM
Subject: Re: browser size when testing resize text and text spacing
← Previous message | No next message

On 10/04/2020 18:50, glen walker wrote:
> When testing for 1.4.4 resize text and 1.4.12 text spacing, is there a
> "reasonable" browser size to test with? If I zoom the text to 200% or I
> apply CSS to adjust the line height, letter spacing, etc, often times the
> page looks good in what I consider (personally) a decent sized browser
> window. But if I shrink the width of the browser, at some point, text
> sometimes overlaps or is truncated.
>
> 1.4.10 sort of talks about a browser size (you can set the width to 1280
> then zoom to 400% to effectively get 320 pixels) but the browser size isn't
> mentioned with 1.4.4 or 1.4.12.
>
> If 1.4.4 and 1.4.12 look good in a browser down to, say, 600 pixels wide,
> but then text overlaps smaller than that, would you report it as a failure
> but with a lower priority? But if overlaps happens at a larger size,
> report it with a higher priority?

Welcome to another gap in WCAG :)

Starting with the normative and explicit side, each SC (with exceptions
such as 1.4.10) needs to be tested for all responsive breakpoints - if a
site does use a set of responsive adaptations/styles at different
browser widths, text sizing/spacing must be tested at those breakpoints.
See the third note under 5.2.2 Full pages https://www.w3.org/TR/WCAG21/#cc2

"New A full page includes each variation of the page that is
automatically presented by the page for various screen sizes (e.g.
variations in a responsive Web page). Each of these variations needs to
conform (or needs to have a conforming alternate version) in order for
the entire page to conform."

e.g. if a site defines styles for mobile at the classic 320 px width,
tablet at let's say 800 px width, and "desktop" large screen for
anything above, then you should test 1.4.4 and 1.4.12 (and most other
SCs) at those starting points too (320 width, 800 width, and then some
size above).

However, SCs aren't necessarily scoped/limited to any particular sizes,
so in theory (and this has been hotly debated) they apply at ANY browser
width/height. Theoretically, you'd need to check/ensure that at any
possible browser/viewport size the SCs pass. But of course, there are
practical considerations - it's impossible to test everything with an
open-ended infinite number of possible width/height combinations. And
also practically, it will be impossible to satisfy many/most SCs for
super-small screen sizes (hence why 1.4.10 was limited to a particular
classic "mobile" size that happens to coincide with 400% zoom).

(see also this side discussion that touches on 1.4.4 and a well-meaning
but incomplete test procedure step https://github.com/w3c/wcag/issues/704)

Long story short: "within reason" try to test various browser
window/screen/viewport sizes. This includes, even for text
resizing/scaling/etc, browser windows that are very small. For resizing,
assuming 320 CSS px width as the lowest reasonable boundary that a
design can be expected to still work / adapt comfortably for text not
overlapping stuff and no horizontal+vertical scrollbars, this would mean
- assuming text resizing is tested using zoom 200% - a browser width of
around 640 pixels (as at 200% full-page zoom that shakes down to 320 CSS
px width). And then I'd generally resize/enlarge the browser window, and
observe if there are any instances where stuff overlaps/gets cut off/etc.

As for reporting failures, and priority, that's your call really. In our
testing, we try to give a (subjective) "severity" to failures. In the
case of text overlapping or being cut off, we're generally guided by how
bad the overlap/cut-off is, and not necessarily at which resolution/size
it happens. However, we do stress that it's mostly a *subjective*
assessment of severity, and that in the end, all failures need to be
tackled regardless.

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke