Body Text Fluent Readability #129
Replies: 13 comments 6 replies
-
|
@mraccess77 Thank you for doing this, I think this is a great starting point for where we are going with this as we move forward. |
Beta Was this translation helpful? Give feedback.
-
|
Really nice Jonathan. This is miles better than the existing supplemental guidance, and does a good job of outlining a template for other sections. Some technical comments for clarity while I'm here reviewing, also some of my suggestions below are toward swapping out to plain language: Under How it Helps (changes in bold)
Under DescriptionThis chunk:
Should be listed last. But also in reading, and yea I realize this is copied from the other thing I wrote, LOL, but I had to read it twice, so here's an alt that I think is more clear (still needs to be last I think).
OTHERAs part of this guidance, we do need to flesh out the "reference font" comparison discussion to clarify which fonts and how to compare, as that is all we have at the moment due to the lack of concrete and consistent font metrics. PADDING and LAYOUT: body text needs padding, and limited number of characters per line, a certain minimum line spaceing, etc etc. And the "line-height" and "letter-spacing" properties are relative to the font, and are just as unpredictable as the size and weight problems, so again, a reference index is needed and not an arbitrary "set line height to nnn" kind of thing... |
Beta Was this translation helpful? Give feedback.
-
|
+1 for this approach, tone, length, etc. to meet Supplemental Guidance Requirements Analysis |
Beta Was this translation helpful? Give feedback.
-
|
[above edited, so this comment no longer relevant] One idea is to use the "Support" section for "how which technologies support it or not" when that is needed (e.g., printing customized text in HTML, EPUB, PDF, etc.) If we go with that, then what's the "Support" section above probably would probably go in the "Description" section. |
Beta Was this translation helpful? Give feedback.
-
|
Bring in more detail about upper bound of text. |
Beta Was this translation helpful? Give feedback.
-
The short answer:Is the "ideal" glyph size range for "normal" vision is 0.2° to 2° subtended onto the retina. Longer answer0.2° to 2° is 12 arc-minutes to 120 arc minutes. One CSS px is 1.278 arc min, so we get a height of 9.4px, depending on the researcher this is x-height (Legge), or x-height + descender(Lovie-Kitchin). This is a minimum font size of about 14px to 16px in Helvetica, or in print 10.5pt to 13.5pt. Upper boundIf we base the smallest font size on x-height, and then the largest font size on upper case height (Because headlines are often all caps) we end up with a naturally limited range. If the minimum critical size is 9.4px, then the max glyph size is 94px. If we use uppercase for the upper bound, then the max font size is 130px, which is larger than desirable for web content, implying that the "major" upper bound is self-limiting. For body text, the minor upper bound I suggested previously is based on 20/40, i.e. double the 20/20 size. So let's say this is a 36px font, that is about the maximum usable size for body text that is not zoomed by user. |
Beta Was this translation helpful? Give feedback.
-
|
Also, the Legge/Bigelow 2011 review paper on print size is a generally good overview. Legge, G. E., & Bigelow, C. A. (2011). Does print size matter for reading? A review of findings from vision science Some of the research I've been conducting for SAPC/APCA extends some of these concepts to self-illuminated computer displays. |
Beta Was this translation helpful? Give feedback.
-
|
ALSO, while we mostly discuss desktop and mobile devices, it is worth noting the other extended use cases:
|
Beta Was this translation helpful? Give feedback.
-
|
@Myndex for the upper bound I think it would be helpful to describe how 36px applies to. On the surface I believe that is around 27pt text - but it seems like it depends on the size of the user's monitor and the resolution. |
Beta Was this translation helpful? Give feedback.
-
Hi Jonathan @mraccess77 , CSSFirst, yes, it partly depends on monitor size and resolution, those being things the user has direct control over. 1px is the canonical CSS unit, defined by the CSS reference px which is a visual angle of 1.278 minutes of arc, and therefore independent of the actual monitor size and resolution, with the reference being a 96ppi monitor at 28" away. 36px = 27pt. But again these are font body sizes and not x-heights. As I am constantly accused of being too complicated, I did leave out a lot to try and minimize, so I didn't cover the minutiae of the upper limit size for body text. In the case of larger fonts, where a display font might be used, it's useful to know that a display font typically has a smaller x-height (ratio) than a font used for column of block text, meaning that the ultimate font size is set larger for the lower case display font to render the same size as a font designed for block/body text. In the world of print, a newspaper might print at 8pt, to cram in as much as possible for a given amount of paper (economics). A quality publication like a magazine is more likely to be between 10.5pt to 14pt, 12pt being the "accepted ideal norm". if 12pt is the design anchor size, most related text like headlines, sub heads, block quotes, are all going to be various amounts larger. Photo captions are often a bit smaller. A blockquote is usually a number of lines and often qualifies as a body text, and a sub head does as well. These are typically 150% to 200% of the main column/body text size. So if the main body text is 13pt, then a called out block of body text for a quote or subhead could be 20pt to 26pt. Only for the Body Text DefinitionIt's important to mention that the upper bound we are talking about HERE is not the ultimate upper bound for text size, which is around ~130px, but the upper bound where something is no longer considered "body text" and is then just fluent text, regardless of the number of lines. I am basing this in part on the spatial frequency pivot point where color/luminance becomes the greater influence on perceived contrast than spatial frequency. And also on use cases where something still qualifies as a vlock of body text, such as in an enlarged blockquote, as in the example below from Medium,com.
Now to be clear, I do not endorse Medium,com as a well designed site, for instance the page luminance is too high and there's no dark mode. But the example here serves the point regarding the range of font size usage. In this example, the main body text is 21px, the blockquote body text is 30px, the remaining is not body text but fluent text, headers are 22px to 48px, and the photo captions are 14px. Using the 21px body text as the design anchor size, then the following ratios are relative to that body text size in this example:
And again, I am not suggesting this is idea or best, just an example of real world use cases. TL;DRThe upper bound of a 19px x-height as mentioned in this thread is only for the definition of body or block text, not for an actual limit. It is rooted in classical design concepts and related visual perception science. |
Beta Was this translation helpful? Give feedback.
-
|
All I know is that 36px font looks very different at 800x600 than it does at 1980x1080 resolution. It's much smaller at 1980. I understand that if you were to set width to device-width you are supposed to get a situation where content would appear the same. |
Beta Was this translation helpful? Give feedback.
-
Hi Jonathan @mraccess77 I think I understand your question now. And here's how that works: No, it is not automatic, and is dependent on how the media queries are set up. Media queries are just a "switched" section in CSS. Inside that switched section, you place whatever CSS selectors and properties you want to respond to the different media size. But it is up to the author to determine what any of that is. And also, "width" means the browser window, not any physical device. In some cases you are in full screen mode, such as on a mobile device, and there, sure, width is the physical width, in equivalent pixels. But if your screen is 1920 wide, and you make your browser 2200 wide, the media-query switch will be active for 2200. Part of the reason for this is to protect the user's privacy and avoid fingerprinting device specs. So, I should also mention that we use "width" and "device-width" is now depreciated and should not be used. Did I answer your question? Thank you A |
Beta Was this translation helpful? Give feedback.
-
|
@Myndex I understand media queries and browser width - I also noticed device-width was deprecated. My monitor 24 inch monitor is set to a resolution that is 800x600 in Windows. It maintains an aspect ration of 4:3. I have a pixel scale of 1. At 36px the text on my scree is considerably different sized from when I set my Windows resolution at 1920x1080 at a 16:9 ratio with a pixel scale of 1. On a 15 inch monitor that text would be rendered in a different size as well. A my setup I'm sure the arc for 1 CSS pixel would be larger than what is described. So when we determined the lower and upper bounds - what size display was used and device independent resolution was used to? |
Beta Was this translation helpful? Give feedback.
-
|
A 96x96 CSS pixel square on my 24" monitor at 800x600 resolution is almost 2in by 2in. So it would appear that measurements we have been talking about are based on a resolution of 1920x1080 with pixel scale of 1 and a 24 inch monitor. |
Beta Was this translation helpful? Give feedback.
-
Hi Jonathan @mraccess77 Oh, again I guess I misunderstood what you were asking. The REFERENCE monitor is a 96ppi monitor that is 28" away.A 1920x1080 is 2202 pixels diagonally. If the diagonal is exactly 24" that's 91.75ppi, let's just say 92ppi. The "reference" monitor is 1920x1080 with an actual display-area diagonal of 22.94" i.e. a 23" monitor. The reference size is a combination of distance and pixel density. It does not consider the adjustments a user might make. It is the baseline standard observer. We make the assumption then that each user will either adjust their distance, or adjust the displayed resolution, or use "zooming" to adjust the actual size and resultant visual angle to suit their needs. In your case, you have your monitor set to an effective "size" that is 55% of the default. This is a zoom up to 180% of the default. The native ppi of your monitor is a little less than 92ppi, so at 28" is close to the reference standard. At your display setting and at 28" away, your monitor is at an effective density of 51ppi. Thus, if nothing else is zoomed or adjusted, a 16px font would render at the equivalent size of 28.8px. If we assume the x-height of a 16px font is 9.4px, that is a visual angle of 12 minutes of arc. Setting the display at 800x600 makes the x-height 16.9px for a visual angle 21.6 arcmin. You also mentioned to me that you view the monitor very close, such as at a distance of 6". This then increases the x-height further to a visual angle of 101 arcmin (79px or so). The total increase in size then from a 16px font, is to bring it to an equivalent of 134px, or a total zoom to 840% of the original size in CSS. Based on the information you gave me regarding viewing distance of 6" and the display resolution setting, I estimate an effective near-visual-acuity of LogMAR 0.93 or 20/165. EDIT TO ADD: This estimated near acuity is based on the premise that the user size adjustments brought the 16px font size to to the critical size needed for best readability. I created this chart that demonstrates some of these relationships. At the bottom is the basic equation for calculating visual angle. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @Myndex I'm glad we now agree on what the reference monitor is and how different resolutions can impact effective ppi. Your assessment sounds correct. A couple of points:
|
Beta Was this translation helpful? Give feedback.
-
|
Hi @mraccess77
At the APCA repo, and in a post here, I listed the "SAPC Standard Observer" a set of specifications to use to model a specific reference size, etc.
Yes, I've been thinking of the phrasing "impairments start above 20/25" or something on those lines. The lower bound gets higher as acuity decreases, but the upper bound does not really change. This is because the upper critical size is related not to acuity but to span, the number of letters that fit the gaze and the size of a word that can be recognized all at once. Our maximum reading speed is achieved when whole words are recognized through the VFWA (Visual Word Form Area), the pre-lexical filtering that recognizes whole words and letter pairs. When text gets too big, we only decode letter by letter instead, and that is what slows us down for large text.
Right. And welcome to why visual perception is such a crazy world and hard to fully grok. You are experiencing size constancy. Here's a related illusion: All three people are the exact same size... some look larger due to the context of the background — our brain adjusts the apparent size of things relative to what we expect them to be. And yet another:
Both yellow dots are actually the EXACT same color on the monitorAnd so is the gray square each dot sits on.... yet they look very different. This is due to the context of the dot appearing to be "in" or "out" of the perceived shadow. Because our brain cognitively associates the shadow with darker, the yellow dot is decoded as "brighter" even though it is exactly the same as the browner dot above it... NeuroThese are called optical illusions but they are not, they are neurological illusions. The vision decoding happens mostly in the brain and 62% of the brain is involved in visual processing, with over 20% dedicated to vision. "Sharpness" we think of happening in the eye, but our brain also has sharpening filters, and is constantly working to sharpen the world around us. Close FarSo, when you move close and far from the screen, the letters ARE projecting on a larger or smaller size onto your retina. But your brain cognitively knows the screen is at X position, adjusts your size perception to fit your current distance. We all perceive the world not as it is, but how our brain processes and filters and molds reality to a "cleaned" image. |
Beta Was this translation helpful? Give feedback.
-
|
In terms of reading for users with low vision - the upper bound may need to be adjusted- not disagreeing that fluency may dip - but there are other factors such as fatigue etc. Too large of text is an issue for users with low vision - but other factors complicate this so it's not as straightforward in my opinion for this particular group. |
Beta Was this translation helpful? Give feedback.
-
I agree — I'm looking at the upper bound in the context of text that is zoomed. The smallest body text needs to be zoomable up to 80px to 92px or so... then the question is how big should the larger fonts be increased. The examples page is using 120px for the largest text IF the smallest text is raised to 96px. EXAMPLE PAGE: https://www.myndex.com/WEB/TextZoomExample And that largest size is relative to a page that at 100% is a 16px body font and 36px headline font. |
Beta Was this translation helpful? Give feedback.
-
User Needs
High school student with 20/200 vision
Problem: I cannot read text when it's too thin, small, and/or faint.
Works Well: Text that is not too small, is regular thickness, and not faint allows me to read fluently.
Teacher over 50 with 20/40 vision
Problem: I am slower at reading text when it is too thin, small, and/or faint.
Works Well: Text that is not too small, is regular thickness, and not faint allows me to read fluently.
What To Do
How it Helps
• People with vision conditions may have reduced contrast sensitivity which makes text that is faint or small and thin, difficult to read.
• People with low vision have a reduced ability to focus. This makes reading smaller text difficult or impossible.
• Thin font strokes reduce contrast and may not be seen by those with low vision.
• Those over age 40 are often not be able to focus closely, and may need to hold reading materials farther away. This prevents them from holding books or mobile devices closer to make the text bigger.
• Younger people under 20, and especially children, have limited contrast sensitivity. Contrast sensitivity also decreases as people age. For these people, faint text or small and thin text may take longer to perceive.
Sufficient size, weight, and contrast allow users to not have to zoom in to make text larger and lose context of other content on the page. If the text is large enough but has limited contrast users may only need to enlarge text to make it easier to read from a contrast perception while decreasing fluency.
Description
Body text is a block or column of more than two continuous lines of text.
Note: This is relative to the non-zoomed initial page load at 100%
Getting Started
When designing content
This guidance aims to ensure that users have sufficient font size, color, and weight without having to create their own stylesheets, use browser zoom, or change settings in order to have a baseline level of fluent reading.
The minimums discussed do not guarantee that this will be enough for all users with low vision. Many users with low vision may need larger text, more bold text, and high contrast to read text. Thus, it is important to not prevent the user from adjusting these settings. Similarly, it's important that text not be an image of text so that users can adjust these settings.
Factors related to contrast: Body text is substantially impacted by line height and other whitespace contrast metrics.
Body text needs to not require scrolling in the direction of the text.
reference font comparison
TBD: Build out this section with discussion to clarify which fonts and how to compare, as that is all we have at the moment due to the lack of concrete and consistent font metrics.
Note:
Examples
{ Examples of barriers. Examples of solutions. }
Support
A broad set of technologies generally support the needs discusses in this guidance. Because some technologies do not support customization of text and customization of text is often complex - this requirement applies across technologies.
Creators need to consider both on screen and print materials when content can be created such as with CSS media queries for print of web content.
Related WCAG
Related Resources
Editorial Notes
This is a sample draft of supplemental guidance to help the group know the level of information needed for this guidance.
notes here
Beta Was this translation helpful? Give feedback.
All reactions