Affordance for oversized text in WCAG Success Criterion 1.4.4: Resize Text #506
Comments
|
Related: w3c/wcag#1671 |
|
Additional note. Again this isn’t really compliant but I also scale the body text down on very small screen sizes where words might be truncated. So my website will be legible on watches. This probably goes against the letter of some accessibility rules, but I feel like it follows the spirit. Apple automatically does this to websites on the Apple Watch, but that setting can be overwritten and custom styles can be applied. When words don’t reliably fit in the viewport, I make an affordance to scale that text down in my work regardless of compliance guidelines as I feel like this follows the spirit, but not the letter of these rules. |
|
Posted in the related issue above, and re-posting here as well. The issue is that 1.4.4 creates numerous scenarios where compliance is a worse and less
If a designer wants to have a big headline on the page, then 1.4.4 starts to
To recap, let’s compare 200% views of the 1.4.4 compliant and non-complaint
Before any rule gets made that non-scaling is ok as long as headlines larger
If you look at watch sized screens, these issues with headlines start to become issues with body and paragraph text as well. TL;DRThere are lots of edge case implications in 1.4.4 that result in severe legibility issues and unnecessary design complications when it is complied with. RecommendationI would recommend specifying that at 1280px, a 200% zoom |
|
Hi @scottkellum thank you for the comment. As this is posted in Silver, I should point out that 1.4.4 does not apply, that is WCAG 2.x, and not a part of Silver at all. Reading your post above it's almost like reading what I wrote on the subject a couple years ago with nearly identical examples. I'll need to dig up that post where ever it is, but here is the direction we have been working on for Silver:
The answer is: Do not use "percentage zoom" as the criteria.The correct criteria is to focus on the rendered font size. The canonical unit is CSS px. The important font metric here is x-height. Unfortunately at this time, CSS does not have a useful way to set font size based on x-height, so standards as based on a typical x-height that is ½ the font body size — i.e. a 16px font is assumed to have an 8px x-height. That said, and assuming a 12px minimum for content text, users need to zoom text up such that the smallest text can be zoomed to an equivalent of ~88px, and no text that is zoomed is forced to be larger than ~120px (i.e. large text is kept under 120px). I.e. the total amount of zoom should be less for text that is already larger. This is not controllable by the author, and is in the hands of browsers developers. Hence the problem. Thank you Andy Andrew Somers |
cwadamsoforacle
added
status: assigned to subgroup
|
DRAFT RESPONSE: We believe the question has been answered per Andy's response #506 (comment) . I hope this answers your question, if it does not, please feel free to follow-up. |
|
@ChrisLoiselle I’m not sure I entirely agree with @Myndex that x-height is the solution for 1.4.4 issues specifically. This solution seems more focused on the recommended minimum body font size as opposed to issues with 1.4.4 resize text and I agree, x-height would be far more useful than font size there. If I were to make a recommendation, I would recommend that at a viewport of 1280px, using browser zoom you should be able to increase the base font size (and x-height, and all other font metrics) by at least 200%. Larger text should never get smaller than the base font size (or I agree with @Myndex here, if we can use x-height it would be better). Still, when talking about proportional rates of scaling, using percentages to describe that scaling is helpful. Also this was more of a comment on issues with the spec rather than a question. I do appreciate @Myndex’s response and bringing x-height into the loop is helpful. I hope to see issues with 1.4.4 solved at some point. Regarding if this is the correct place to have this discussion, I was pointed here by a few people. Happy to have this discussion elsewhere. My goal is to get this issue addressed and please excuse me if this is not the right forum. I would appreciate being pointed to a better forum to raise these issues. |
|
Hi @scottkellum The reason I am pushing away from "percentages" is that a percentage with no context does not address a user need. Silver is about defining user needs first, then finding solutions. The User Need for Critical SizeIn this context, the user need relates to the "critical font size" (and also the critical contrast) see Lovie-Kitchin's research. The "critical" font size is the minimum font size needed for fluent readability, that is, reading at the best speed and comprehension. For normal/near normal eyesight, the critical font size is an x-height that is two times the minimum acuity cap-height of the letter E. In other words, if the minimum size for legibility of an E subtends a visual angle of 5 arc minutes, then the critical x-height is 10 arc minutes. This implies a font body size of 20 arc minutes if the x-height is 0.5 of the body size. It also implies a cap height of about 16 arc minutes, which further implies that the "minimum critical font size" is about three times the acuity limit of legibility. CSS px are based not on screen size, but on visual angle. A CSS px relates to the CSS Canvas abstraction layer, and was originally set at 1.278 minutes of arc visual angle, this is essentially one device pixel of a 96ppi screen at 28" viewing distance. For normal vision, the critical size is a font-size around 16px (which happens to be the standard font size), which is similar in readability to a 12pt font in print. For someone with low vision, the critical size can be larger than 80px, which is a 16px font at 500%. Many websites use 14px or 12px fonts for content, and at 500%, that is 70px or 60px respectively. Even at 500% this does not meet the needs of low vision users of 20/100 or worse. The "200%" of WCAG 2.x barely accommodates 20/40, and 200% does not address the needs of low vision users. Out of context, 500% brings it up to about 20/70-ish. Legally blind is 20/200, and low vision is the range between approx 20/70 to 20/200. The Particular Pertinence Of pxOn the other hand, if the standard were to say that "must be able to zoom the smallest font up to an equivalent of 90px" as an example, then we are addressing that user need very directly. 90px is an 18.4px font at 500%, or a 12px font at 750%. And a corollary here is that there is a maximum critical size, in the area of 94px to 110px or so, where readability also decreases. So just raising the largest fonts on a page by 500% is a non-starter! A 36px font at 500% is 180px. What we want instead is to increase the larger fonts to no more than 120px. That means a 48px font is increased no more than 250%. What I am trying to illustrate is how a single, across the board, zoom percentage does not meet user needs. The user need is best met with a user customization/adjustment such that: The smallest content font on a page must be able to zoom up to an equivalent of 90px, while the largest font(s) on a page are zoomed up no more than a size of 120pxHere's a chart that illustrates some of this:
I have to attend to another project deadline right now, but I hope that answers this more fully. I'm happy to continue the conversation if you like. Andy |
|
@Myndex Thanks for your explanation of this. It’s good context to have.
This statement makes one critical assumption, normal vision. People who might rely on zoom might not have “normal” vision and I know people who set their default to everything from 14px to 24px. Additionally the proportion of screen size to font size is very important here, and why I am wary of using pixels. Controlling this proportion is why people use fluid/responsive type sizing solutions that result in the issue at hand. Read this paragraph before responding please 👇🏻 I do see your point that if someone has a very large preferred root font size, zoom would make that font size far too big resulting in 1.4.10 reflow issues. It sounds like relying on CSS pixels instead of percentages gets us into a situation where we can reliably indicate size changes. Isolating the variable of page scaling and removing the variable of user font size adjustment. Note: that I have been working on the web for a long long time, I read specs, and know how CSS works on many fundamental levels. CSS fundamentals are not where I am looking for clarity here. Applying those fundamentals to solving this issue with WCAG user needs is where I am looking for. I understand you likely field a lot of questions from people who do not understand what a CSS pixel is but that person is not me. (I even wrote an article on CSS pixels way back when high DPI devices were coming out, although the approach is dated and I don’t advocate for it anymore) |
|
Hi @scottkellum
I think you are misunderstanding the context, as I am not making any such assumption. As I state in my post, the people that need zoom do NOT have normal vision. Normal vision is the research-baseline for critical font size, and then we look at how those with low vision are impacted and how that affects their minimum font size. Again Dr. Lovie-Kitchin and also Dr. Legge have done a great deal of work here over many years of study, and are the canonical resource.
CSS px are the only really canonical, non-arbitrary, device independent unit in CSS — vh and vw literally lock you to a devices arbitrary dimensions and is otherwise undefined. rem is also undefined except arbitrarily by the user agent at its root. And em is as useless as percentage, it is means nothing without a complete context. FWIW I don't like calling px pixels, as that is not an accurate descriptor; the CSS px can be any fraction, which is certainly not true of device pixels. When I was originally starting the work in research for contrast and then readability I was looking at various units that are relative to the observer, not the device. I can tell you that most researchers use visual angle (as subtended onto the retina) for specifying the size of stimuli. Snellen's 20/20 is literally based on a capital E with a vertical visual angle of 5 arc minutes. "Perfect" normal vision is actually 20/16. The CSS px is the CSS canonical unit that is also based on visual angle, and is device and screen independent. When making a standard such as WCAG 3.0, it is important to be technology agnostic, and using the px for the standard directly relates it to human vision in a way that is more intuitive and easier to understand than the specification of "visual angle in arc minutes". |
|
@Myndex thanks it sounds like the first assumption I made about your proposal was incorrect, which is why I asked. I am still unclear as to what your proposal is, but I appreciate your fluency in defining pixels. It seems like we agree that 1.4.4 is flawed, and I am glad we both are working towards addressing the issues with it. I would be happy to have a video call to discuss our different ideas around this issue as I always find discussing nuances of specs easier in that format. |
|
Hi @scottkellum This is one of several issues that are facing us in the newly restored Low Vision Task Force. Contact @ChrisLoiselle for more information on involvement. Are you already a W3 member? Typetura looks interesting. |
|
@Myndex Thanks, I have participated in a number of community groups but the membership fees are far too high. Maybe in a few years when my business has matured a bit I’ll find some budget. |
|
Hi @scottkellum , I am looking to clarify this issue. Is this issue something that can be closed per your recent discussion with @Myndex or are you requesting a meeting with Andy to discuss further? Thank you in advance for clarifying. |
|
What does resolution of issues look like to Silver? I assume this is resolved when 1.4.4 is amended or replaced with something that addresses these issues. Maybe this group takes issues raised here and considers them to make recommendations to the WCAG. Sounds like @Myndex understands my issues with 1.4.4 and is working to fix them so if that is the criteria for closing an issue, then yes this is resolved. I am still unclear as to @Myndex’s approach to solving this, I think that is beside the point of the issue. We agree that things need to change and I am happy with that. |
|
@scottkellum We are organizing the upcoming work to migrate WCAG 2.x to WCAG 3. This is going to take a while but I am reassinging this comment to the milestone related to 1.4.4 to ensure it is considered when that part is worked on. Thank you for taking the time to file a comment and for your patience while we get to this portion of WCAG 3. |
rachaelbradley
removed
Subgroup: Visual Contrast
|
Since the zoom problem, not to mention at the x-height problem, is a big part of the work we've been doing, I'm putting this post here to update this thread with more recent information. The fact that browsers (for the most part) only zoom by percentage is part of the problem the other part is that different browsers handle their zoom of the page or independently zooming text, in different ways and there's really not a standardization there. And as some point out, and which we've been talking about in the R&D for APCA / WCAG 3.0, zooming all text by a percentage does not serve the needs of users. There is a range of "critical font size" and in an ideal world all text would remain within that range for that user. But additionally, the current 200% in WCAG 2 is really not enough. The difference between 20/20 and 20/40 is 200% (!!) Low vision needs much more. For desktop work, 500% for body text is reasonable and useful, accommodating somebody at 20/100.¹ Low vision is considered somewhere around 20/70 to 20/80 and worse. Technically, 20/80 could need 400% (all things being equal, of course there are a lot of wiggle factors here). Unfortunately, 400% doesn't work on devices smaller than an iPad in portrait mode or an iPhone in landscape mode. In fact 200% is really the limit for 16px body text & iPhone in portrait mode—and this is only considering body text. When talking about large headlines, they can't be anywhere near 200% for mobile devices. (again all things being equal depending on delay scale factors etc.) In this post in discussion 39 on use-cases at the readability forum, about halfway down is the section on spatial frequency (size) and zooming, and a link to some examples. These show that if we really want to accommodate low vision, we cannot be zooming all text the same percentage, period. At the moment this can't be a guideline because the technology isn't there, except with a polyfill, and we can't require a polyfill guideline. What we need is browsers to have get together on zoom.NOTE: |
|
Hi @alastc there is a lot of good information and discussion in this thread, IMO it should be labeled for MIGRATION, visual contrast/visual presentation so it comes up in those related searches. |
Regarding https://www.w3.org/WAI/WCAG21/quickref/?showtechniques=144#resize-text
It seems an affordance should be made for when text gets too big for words to reliably be expected to fit within their container. Most websites have a breakpoint or use another technique to scale headline styles down when they become oversized for the area in which they occupy. This is because text overflowing a container can result in far worse legibility issues than text not uniformly increasing in size.
The intent of this seems to be around ensuring body copy and smaller text on the page can reliably and consistently be scaled up so that people can read the content of a website. As headlines are often already big, they should not need to increase in size at the same rate, or be allowed to scale down when they get too big for the space provided.
This is a result of this issue opened on my project in which it was discovered that just about every responsive website’s headlines fail 1.4.4: Resize Text: Typetura/Typetura#44 — It should be noted that I’m not looking for a pass on the demo site I made that the poster is talking about, but there should be some affordance for the general issues raised in all the examples. Large text should be able to scale down to better fit in a layout.
Mitigation of failure states
There is already documentation of failure states for this: https://www.w3.org/TR/WCAG20-TECHS/F69
However this documentation does not take into consideration the box that is too small may be the viewport itself or an area of the page where the text is already significantly larger than other areas. In both these cases it would reduce failure states and increase legibility to create affordances for text in these two instances to be scaled down.
Internationalization
Different languages have different sized words and text breaking patterns. This needs to be taken into consideration when codifying what affordance needs to be made to ensure text doesn’t overflow containers.
The text was updated successfully, but these errors were encountered: