Failure technique F94 (1.4.4 resize text): remove "1280 pixels wide" step in test procedure #704
Comments
|
taking the example failure code of the technique, if a site (for whatever reason...e.g. under the assumption of "anything below 600 CSS px width is a mobile, and we want it to be app-like and not scale") did the following, the test procedure wouldn't catch it if testing just using browser full page zoom starting at 1280 as suggested in step 2 of the procedure: However, for any user who has their desktop set to something smaller that at least 1201 pixel width (e.g. 800x600 because even though they have a large HD monitor, they need their desktop to appear much larger due to mild low vision), or simply users who don't run their browser maximized but need it, say, to run side-by-side with another application, they'll hit that breakpoint, and land in the situation where the |
|
@patrickhlauke I have applied your suggestion to a number of sites on the desktop, going for the narrowest breakpoint I found where design changes happen, checking for 100% default, then zooming in to 200%. So far, of a few sites I checked that make an effort to allow resize and have RWD, all fail in some ways at the outer bounds of the narrowest breakpoint (including two of our sites, incobs.de and team-usability.de, but also bbc.com, funka.com, paciellogroup.com, deque.com and WebAIM.org). So this seems maybe not impossible, but very hard to meet (nomensa.com and guardian.co.uk seem to pass). Is going for a narrowest desktop breakpoint (outer bound) at 100% and then scaling to 200% a realistic scenario for LV users? Would they not rather start with a large browser window and then zoom in to potentially a lot more than 200%? |
|
the normative wording of the SC does not set any lower bounds, so i think it's academic really? unless we retrospectively want to set lower bounds for the SC, i think the fact that the SC states pretty much "users should be able to resize text to 200% its original size", and the "full pages" note says that SCs apply to all variations (including MQ breakpoint variations), brings us to the logical conclusion that this should be tested not at some arbitrary "1280 pixels wide" size, but at each breakpoint at least. it will STILL leave some situations (e.g. when the size starts just on the boundary between breakpoints) that can potentially be missed out, but it increases test coverage considerably over just saying "yeah, just test at 1280"... |
|
I dig your all page variations argument but I think the implications for text resizing haven't really been thought through when that was stated. I also dig your "smaller than 1280px" argument (people may want other stuff next to the browser) but going for the smallest breakpoint and scaling up from there seems as arbitrary as settling for 1280 - and hard to do in practice, as evidenced by many sites tested so far (I have added a few more to the list above). Why not go for 320px? At that point, nearly everything will break. We should be careful asking for something that we find very hard to accomplish ourselves. |
|
when you say "break", what kind of breakages are you seeing? reminder that this is not reflow, so not about horizontal+vertical scrollbars, but just about text overlapping/breaking out of its boundaries, being if we want to talk about adding a lower bound to 1.4.4 in WCAG 2.2 (unless 2.2 will have the same "we can't touch the old SCs), then sure. but i'm going by what the current normative SC text is, and what the "full pages" note logically implies. |
|
If I must:
All of this unrelated to reflow. |
yes, i'd consider that a failure. well spotted. will go and flog the person responsible :) so it seems having a lower bound will be necessary, similar to reflow (though making it a "down to" rather than a hard value of "just when it's at this size). however, do we agree that, as written today, the SC applies to situations other than just the once tested at 1280 pixels wide, and if so does the technique need to be changed to remove that implication? |
|
(the lower bound being something along the lines of "test at all breakpoints if it's a responsive site - per 'full pages' note - but for viewport sizes that fall below 320 CSS px the SC is not applicable anymore" as a very broad requirement. still leaves liminal cases with starting viewports close to breakpoints, but provides much more consistent and logical coverage than "just at 1280") |
|
I agree that SC 1.4.4 testing should occur at each breakpoint variation of page. This does certainly increase the amount of testing necessary to verify conformance -- but ultimately it is what is needed to truly make sure the variation can indeed each be zoomed to 200%. |
|
@patrickhlauke wrote:
For the original intent, the keyword there is that it was the authors default starting point. It was written pre-media queries, so there was no mechanism to change text size based on viewport size. There was a desktop usage assumption. @mraccess77 wrote:
That isn't what we have discussed previously. Also, to quote myself from last year:
If you look at the test page on a mobile you can zoom in on the VH set text because of the layout method for pinch zoom. Given that, unless you disable pinch zoom (if that's still possible?) I don't see how you can fail 1.4.4 on mobile devices. So I'd argue that the 1280px step makes sense for the original intent of the SC, which assumed a desktop starting point. In the case where a site switches unit to VH/W at certain sizes (Patrick's second comment), the key thing to test is whether you can get to 200% from the assumed (desktop) starting point. If 1em at 1280px wide is 16px, then can you get to an equivalent of 32px at some point? If the breakpoint is 600px then probably yes. The interesting thing about that example is that the height of the screen is also relevant as you used VH units, so the results could be different if you use 1280x1024 or 1280x768. Perhaps we should add a height as well? If we were talking wholesale change, I'd suggest replacing 1.4.4 with a minimum text-size SC. E.g. Text must be at least 10 CSS pixels across all variations of a page. (So it would be 40px at 400% zoom.) In today's context that would make more sense. |
and that is still the case, no? when talking about "200%" it's "whatever the text size is set to by the author, times two" (and not "200% of what a regular unstyled 1em is normally sized to in the browser").
you can if the site prevents pinch zooming / user-scalable (though most modern browsers now ignore directives to do so, or provide a way for users to override this)
then that needs to be put in normative text somewhere? and it still seems inappropriate, because essentially saying "just zoom/make your browser window bigger or smaller, or a combination thereof, until you manage to coax the site into letting you increase text size to 200%" isn't really good for the user (but yes makes life easier for testers i guess)
nobody here is talking about "desktop" versus "mobile" (and heck, it's high time we stop thinking about those labels). i'm talking about the fact that there are many different possible "desktop" scenarios (depending on whatever resolution the user is actually running their OS at), and that it's facile to just assume 1280 width.
this is all very much based on IFs and assumptions. what if the site defined lots of lovely micro-text (which is too small for 20/20 vision users to read, let alone LV cases), and then the "small screen" styles also force the size way back down to micro-copy even smaller? then the answer is probably no. point is, again, that normative SCs shouldn't rely on "well how likely is it?" / "nobody will do this, surely?" / etc assumptions which invariably lead to big barndoor-sized loopholes otherwise. the resize text SC thankfully doesn't have normatively some hardcoded EXACT viewport size defined - compared to the discussion about reflow...so let's not now retrospectively introduce it (or suggest it) in misleading test procedures. |
"i see you object to the test defining a width. maybe we should also define a height" ... |
|
contrived perhaps, but more fleshed out live example https://codepen.io/patrickhlauke/live/rbREKe |
|
additional, worth noting: all the discussion here about needing to test each breakpoint doesn't preclude sites from using RWD approaches to fulfill the requirements of the SC. if i start off at one breakpoint, and while attempting to enlarge text to 200% it jumps to another breakpoint, that's fine as long as i can still reach my user goal of "resizing text to 200%". it's not meant that this needs to happen in a self-contained "must be able to resize to 200% without jumping to another layout/breakpoint". but i would then also need to test using that other breakpoint that i wandered into as a starting point to see that from that, i can also resize to 200%. and indeed at that stage, it would make sense to include a lower bound limit (heck, be it 320 CSS px width for / 256 CSS px height) at which it's unreasonable to expect sites/authors to cater for a further 200% zoom. |
I'm afraid we can't avoid it when there are different zoom mechanisms on each. The scenario where you can significantly increase text size is based on desktop style zoom, and 1280 is a reasonable starting point. I.e. if desktop browsers are 'accessibility supported' this should work. Sorry, I know it winds you up but that's the scenario that works.
I don't see how what you're proposing helps. If there is no starting point for testing a 200% increase, how do you get any kind of consistent result? If I set a breakpoint at 350px, how can I comply? It isn't physically possible. |
|
@patrickhlauke @mraccess77
Alternative text: Screenshots of 8 websites at 320px viewport width and 200% zoom (levelaccess.com, paciellogroup.com, webaim.org, bbc.com , guardian.co.uk, funka.com, deque.com, team-usability.de). All show various forms of clipping, element overlaps or unreadable text due to background color not having sufficient contrast. It often comes down to word length (words like accessibility, when not in a small font, being too wide to fit) - and setting a lower text size at narrower breakpoints would defeat the aim of achieving 200% (unless there is an exception for text above a certain size - headings, etc,). You also see trucated menus, placeholder texts, etc. The quick test for sites in my initial sample (all of these strive to be accessible / meet WCAG) was already mostly negative at the outer bound of the narrowest breakpoint defined in the site's CSS. At 320px, NONE of the sites that I have so far cared to test has passed. I frankly think that going for any breakpoint defined is a non-starter. I could imagine setting a lower bound such as 640px or 800px and demand that 200% text resize can be reached for all viewport widths between that lower bound and 1280px (or even from lower bound upwards). But at 320px it seems nigh impossible to meet. |
this is in reference to "text resize". 200%. this is a separate discussion to 400%
per "full page", i need to test for each breakpoint. there's my starting points. that doesn't need to be said in the failure technique's test process, as the need to test each breakpoint / variation is in https://www.w3.org/TR/WCAG21/#cc2
which is why we should ideally refine the requirement for testing at all breakpoints to define a lower bound |
If the lower bound was set to 320 CSS px, then as soon as you try to zoom and the viewport goes below 320 CSS px, it wouldn't apply anymore and be exempt (if we set that as the lower bound) so treat lower bound as "down to but excluding". as soon as the viewport goes below that bound, the page is exempt from failure. so in essence, all those examples would be exempt (as i assume they're now in effect 160 CSS px width) |
|
Also
this is not about winding me up. This is about the SC normatively NOT having any kind of limitation to width/size/etc, and this failure technique's test procedure introducing one through the backdoor (and again reminder this is about the old inherited WCAG 2.0 SC 1.4.4, which now under the "full page" additional note about variations based on width in 2.1 now needs to be tested for each variation) |
|
Hi @detlevhfischer -- I wasn't suggesting 200% of a 320CSS pixel layout but that at 320CSS pixels or any of the other breakpoints that the text size must be 200% of the size of the "primary" breakpoint. I guess this means that the actual font size is increased to 200% or that the page has a scale factor when combined with the font size produces the desired 200%. Scrollbars are always allowed with SC 1.4.4 -- but it appears that is not the default such as sites that don't set a minimum width. |
there is no "primary" breakpoint though. unless we want to explicitly define "we, in WCAG, only want to consider desktops at this particular width times height as the 'default'" which i think would be very shortsighted. the whole point of sites that adapt (be it using full responsive approaches, or simply not locking to a particular width/height using absolute measures) is that all possible variations are idempotent. thinking about one particular size being "primary" (or "desktop", or whatever) and all others being variations is a fundamental flaw. |
|
@patrickhlauke Ah, OK, I misunderstood. So working backwards from your lower bound of 320px, meeting 200% text size wound then mean setting the viewport width to 640px and scaling up to 200% (provided that text size is not changed at breakpoints). Breakpoints below would only be consided up to the point where the result of zooming in does not yet undercut 320px viewport width. Correct? |
|
@detlevhfischer tentative yes for the zoom scenario where zooming affects CSS viewport dimensions. of course for other methods that allow text resize (e.g. mobile/tablet pinch-to-zoom, if you want to check there as well; or testing any custom text resizing buttons a site/page may provide itself instead ... any other methods where changing text size does NOT affect CSS viewport dimensions, basically) you'd still want to test even at 320 CSS px size itself, if that's a defined breakpoint (if THOSE are the mechanisms relied upon, as really only one of them is needed; and if testing specifically on mobile/tablet is part of your audit, then you need to obviously test mechanisms that are available in that environment as well, and can't just rely "don't need to test, as user can't do viewport-dimension-changing full page zoom there, since that method of resizing text is not even available on those platforms). in the case of mobile/tablet zooming (which does not reflow/change CSS viewport dimensions), unless the site actively suppresses pinch zoom, this should always pass at this size (as it just results, in worst case, in horiztonal AND vertical scrollbars) |
That's one way of looking at it, but on the other hand if you have breakpoints prior to 200% (from whatever starting point), it is un-testable. You will switch page variations before you get to 200%. E.g. you have a break point at 960px wide and another at 600px, it is logically impossible to test the 960px break point with zoom because it changes before you get to 200% (480px). That's why the current understanding doc for reflow (and even recent updates) say "It is not required to achieve 200% text enlargement at every breakpoint, but it should be possible to get 200% text enlargement in some way." For mobile-browser layouts it is not relevant, those devices will pass 1.4.4 unless pinch zoom is disabled. For desktop-browser re-flowing layouts (more useful for low-vision) the user can zoom and/or change window size. It is difficult to buy a laptop or monitor that has less than 1280px width, and if you change the resolution to 800x600, it's already increased the physical size of the display so is already partially 'zoomed in'. In the 'useful' scenario, if you take each breakpoint above 640px as a possible starting point, what does that gain? It seems like adding a lot of testing for very niche cases (that would generally be caught from the current method). |
as i said in the previous comment here #704 (comment):
That is the understanding for reflow. This is a failure technique relating to the SC for text size. Are you saying the understanding for 1.4.10 now applies caveats and limitations to the (normative) interpretation of when 1.4.4 applies/needs to be tested (and overrides what the "full page" conformance requirement says)? [ed for even further clarity] there are two issues here:
That's certainly...an interpretation...saying to users that they're already running their computer "zoomed in" so a site doesn't need to allow text resizing up to 200%? If they're running it at that resolution, it's because that's their base/comfortable default size. If a site now, at this size, sets its text too small for the user to read, we're then saying that it's tough and there's no requirement on the site to allow the 200% resizing? /cc @mraccess77 who i gather is a user running 800x600 ... thoughts? |
|
I think the next step on this one would be to write a test procedure that accounts for page variations (primarily break points). I'm still struggling to see how to define that when you can change breakpoint before you get to 200%, such as the 960 to 600px example. |
start at each breakpoint with your testing. X is the size of the text at that point. is there a way to reach 2X text size? as you increase text size, you may trigger/wander into a new breakpoint, and that may even have a different base text size...however, that's irrelevant, you're still trying to reach 2X. carry on until you can confirm whether or not you can get to that result. then, move on to the next breakpoint, make the default text size THERE your new X value, and repeat |
|
or, in a more structured/bulleted way... for each discrete breakpoint/layout of the page:
note that different parts of the page may use differently defined text sizes/scale differently. apply this test to all text elements on the page (basically, your main content text may scale, but your headings may somehow be locked to not resize or resize only so marginally that you can never reach 200%...that would be a failure) |
|
the test procedure should not have had that starting point defined for testing in the first place, would be my very general take. and so that testers don't miss any important scenarios, they should test around author-defined breakpoints at the very least. |
|
coming back to this a bit late, but: if we did have something that says, roughly, that 320 CSS px is the lowest limit...would this not mean that any site that has a mobile-friendly view at 320 CSS px but then suppresses pinch-to-zoom or similar is exempt. worth remembering that resizing doesn't always mean a change in viewport size (or well, document size/page size, to be more precise) so i'm not totally sure if the SC itself needs a change. and I think the only change needed here really is removing the "1280 pixels wide" step in the test procedure for F94 (keeping in mind that this technique is for 1.4.4, not 1.4.10, so concerns about bidirectional scrolling or similar are orthogonal to this test) |
|
perhaps what this does need though is a note in understanding that explains that for user agents where zoom leads to a change in the effective CSS pixel dimensions of the viewport, and where content reflows rather than leading to scrolling, there is a practical limit to the minimum size at which content can be expected to remain usable/readable. however, i wonder if at that point, this should be a pure exemption, or a requirement on authors to set a minimum width for their content (so that once below effective 320 CSS px, for instance, the site is set to force a min-width of 320px, forcing scrolling at that point rather than reflow into ridiculousness... this way, if authors fulfill 1.4.10 and reflow at 320 CSS px, any further zoom can then happily lead to bidirectional scrolling, as long as the size of text can still be changed there... |
it's irrelevant, as the SC applies at any size, so doesn't need to appear to be limited to any particular one. This addresses initial concern of #704 (but that issue has more discussion about the potential need for a normative change for 1.4.4, or addition of note(s) in the understanding, to set some lower bound)
|
There is nothing in 1.4.10 that mandates text has to be larger as long as each variation of the page meets SC 1.4.4. I find many pages that get smaller at 320 CSS pixels. Starting at 1280 CSS pixel width is a good way to then zoom in to 400% there is no requirement for that - as long as you test 320 CSS pixels and each page variation. I do agree though in terms of SC 1.4.4 that we do ideally want to define a starting resolution for consistency of results. I agree logically with @goodwitch that 200% would be effectively 640 width starting at 1280 and that matches the intent of 400% at 1280 reaching the 320 CSS numbers - so ideally SC 1.4.4 would be tested at a width of 1280 as a starting point to zoom to 200%. |
the SC applies to all possible breakpoints of a site though, and arguably all possible sizes too. so this would actually limit the scope of testing some users may have their browser only sized to 800x600 (either their entire desktop, or just their browser window). should they not be able to zoom to 200%? if something happened at that size that prevented them from doing so, that would be missed by only starting at 1280 and trying the 200%. i know this is only a non-normative failure technique, but still... and again, 1.4.4 and 1.4.10 test different things. 1.4.4 is "can i resize the text up to 200%", 1.4.10 is "does text reflow down to a viewport size of 320 CSS px width for mostly vertical / 256 CSS px height for mostly horizontal content". they're not "one is 200%, the other is 400%" |
|
any more thoughts on this? |
|
We already discussed this A LOT and have a closed issue on this from 2018 where we voted on the response as part of 2.1 discussions.
We're not adding anything new is 2.2 that is relevant. So my thought is figure out how you want to do bring this forward in Silver such that it is scalable and meets a sweet spot of fulfilling user need without undue author/test effort. |
|
@mbgower so, bringing this all back to the original question: could/should be "1280 pixels wide" step in the test procedure for F94 be removed or not? I'd still say yes, and it sounds like you agree? |
|
i don't think I've dug into this enough sufficiently to say "yes" or "no". This technique seems to have been introduced in 2.1. So I'm wondering to what degree that start point was chosen because in 2.1 we were focused on it as a 'default'. For instance, it's used multiple times in Reflow's Understanding document, including the notes at the normative text:
My sense is this test is checking for use of viewport units, which it does. It sets up a 'typical' desktop experience as a starting point...
Is your concern that if someone uses C12, C13 or C14 for desktop and then alters their mobile implementation to use viewport units that you wouldn't catch it? Failure techniques are always hard to produce. This one seems to capture a failure. If we want to expand what is caught by that failure, we need to be very careful. |
|
Reflow is explicitly scoped to those sizes normatively. Resize text is not scoped/limited normatively, so having a technique that gives the impression that it is/it should be tested starting with a particular desktop/browser size is misleading. |
|
Do you have any concern that by removing the starting test position you are increasing the failure technique's scope to the point it may result in false positives? That's my concern here. I'd rather have a scoped failure technique and test that consistently and accurately captures a failure than one that doesn't. |
|
what false positives would you get for that failure as outlined in the failure technique (with that example CSS/HTML)? you can either resize the text, or you can't. sure, if you apply the tests to more complex content, you may take more things into consideration (e.g. presence of media queries that change things under your feet when zooming), but that is true for techniques in general (they're not absolutes but apply to the specific examples - if what you're testing differs from the example used in the technique, it's not a given that you'll also pass/fail/be able to use same test steps) |
|
In reality this needs to pass at all page variations - but the concern I have is that many sighted developers have their monitors set to a resolution like 1900+ resolution and when you zoom in to 200% you are at around 1024 or more in the same desktop page variation. At this level you could meet the technique and SC but in reality I don't think most users who need magnification will be starting at that resolution or if they do they would need more than 200%. When WCAG 2.0 came out people where using 1024 or 1280 and 200% of that was 512 or 640 and so that was the expectation at the time of WCAG 2.0 in terms of size. Most laptops issued by schools only go up to 1366 and thus I'm concerned that if people can set the highest resolution and pass that we will miss real world problems that people with low vision run into when they are not using an external display or high resolution monitor. |
|
@mraccess77 note that this specific failure technique would also fail on 1900+ resolution, or any other resolution, as it's showing how the use of |
|
If you proceed with removal of the step, I think we will only end up with each tester choosing to test the way they want with various result depending on each testers. |
|
@goetsu good idea. I'll make another PR to add to the pile... |
|
@goetsu added a note along the proposed lines #1838 (borrowing/bastardising the wording from https://www.w3.org/TR/WCAG21/#cc2) |
…te to 1.4.4 Resize Text (#2630) - Updates the wording in the Reflow Understanding document which discusses the connection between Reflow and Resize Text in attempt to make it clearer - Adds similar reciprocal language into the Resize Text Understanding document Closes #1839 Related: #2101 #704 --------- Co-authored-by: Scott O'Hara <[email protected]>
- Removes 1280 pixels wide step - Removes the unnecessary preamble before the test steps, and tweaks the last line of the test procedure to reference the last step, rather than giving it a number - Additionally, cleans up formatting of the HTML Closes #704 --------- Co-authored-by: Mike Gower <[email protected]>
and others
trying to summarise a lengthy stream of consciousness on twitter https://twitter.com/patrick_h_lauke/status/1122478448986001408 ...
in short:
vh/vwsizing for text is used - per the failure technique)The fear seems to be that if a site uses responsive web approaches, it would be impossible to test as a site could continuously change text sizes for smaller viewport sizes. But this appears to be irrelevant, as the original intent is: from whatever the author defined as the starting size for their text (the "100%" state), can a user get the text to be twice as big without the need for AT. if they use browser zoom, and the site switches layout and makes the text smaller again, then that's a clear failure of the SC.
And per the "Full pages" note https://www.w3.org/TR/WCAG21/#cc2
So, IF a site uses responsive breakpoints to swap out layouts, then testing should happen taking each breakpoint as a starting point. From each of those styles/layouts, can a user enlarge text to twice the size defined there. And if by trying to reach that 200% size they happen to trigger another breakpoint, that's mostly irrelevant to being able to ascertain if, from the starting size tested, the user is able to get to twice the size of text that was presented at the starting size.
The text was updated successfully, but these errors were encountered: