[SEO Audits] Document uses legible font sizes #3174

rviscomi · 2017-08-29T17:44:07Z

Audit group: Mobile friendly
Description: Document uses legible font sizes
Failure description: Document does not use legible font sizes: <body> font-size {#} px (target: >= 16 px)
Help text: Font sizes less than 16px are too small to be legible and require mobile visitors to “pinch to zoom” in order to read. Read more about font size best practices in Use Legible Font Sizes.

Success condition: No font-size style detected on the body, or it exists and is set to at least 16px.

Notes

Alternate approaches could be to query the DOM for the first <p> (or similar) element and test if its font size is >= 16px. Or the audit could scan the entire DOM for text < 16px and the result could be the % of text that meets the size requirements, similar to the PSI source.
If the font-size style is omitted from the body, we can assume it inherits the default font-size of 16px from the UA stylesheet.
The detected font size is included in the failure description.

The text was updated successfully, but these errors were encountered:

paulirish · 2017-08-30T23:52:33Z

query the DOM for the first
(or similar) element...

I think we may want to list ALL offending elements. PSI did have a really comprehensive approach on this one, so using basing this off their work sgtm.

rviscomi · 2017-08-31T15:47:32Z

I'll have to double check their scoring criteria, but the PSI doc seems to point to 16px just being the baseline from which small/large variations are allowed. Eg: 12, 16, 20px. So should sparse 12px text be flagged as invalid? We could also do something like "> X% of text is < 16px" basing off of string length instead of DOM count.

kdzwinel · 2017-09-10T22:14:10Z

PSI doesn't show me a font size warning no matter what (e.g. this page with font-size: 1px). Maybe they no longer check that?

Mobile-Friendly test was a bit more helpful (I had to solve a lot of captchas though). It shows the font size warning when all text is <=8px, but it's enough for one paragraph to be >8px for the test to pass (e.g. this example).

However, that's only me poking a blackbox. Their audit may be also taking line-height, viewport settings, length of text etc. into consideration, and I haven't tested those.

I think that people may expect this lighthouse audit to work the same way as the corresponding mobile-friendly test audit does. It'd be good to know their exact criteria. Is it even possible to get that info?

patrickhulce · 2017-09-11T16:53:01Z

The PSI font-size check is far more complicated than their public document suggests and attempts to account for a host of crazy things. Sticking to a basic font-size property check and allowing a minimum threshold of small text sounds like a good starting point. We should probably also fail this check if mobile viewport isn't already set since even 16px font sizes will be way too small if the viewport is desktop-sized.

rviscomi · 2017-09-11T17:00:50Z

We should probably also fail this check if mobile viewport isn't already set since even 16px font sizes will be way too small if the viewport is desktop-sized.

There's already a separate audit for the meta viewport, so should this one still fail? IMO failing this will obscure the real cause (viewport) and may lead people to dig into font-size which isn't necessarily broken. But it's true that without a proper viewport config, text will be illegible, so I can see it both ways.

patrickhulce · 2017-09-11T17:07:27Z

There's already a separate audit for the meta viewport, so should this one still fail?

There's a precedent in the PWA audits to rely on a check in another audit (just by require('./the-other-audit')) and fail with a debugString that lets them know Text is illegible because of a missing viewport config or w/e which seems fine to do here as well if we explain the causes in the audit "Learn More" link.

rviscomi · 2017-09-11T19:15:42Z

Descriptive debugString SGTM

kdzwinel · 2017-09-13T19:46:46Z

@patrickhulce do you have something like this in mind?

lighthouse/lighthouse-core/audits/webapp-install-banner.js

Lines 74 to 77 in b80d906

    
           const hasServiceWorker = SWAudit.audit(artifacts).rawValue; 
        
           if (!hasServiceWorker) { 
        
             result.failures.push('Site does not register a service worker'); 
        
           }

patrickhulce · 2017-09-13T20:35:09Z

@kdzwinel yeah that's exactly what I was thinking about :) not the prettiest, but easy to reuse the logic you need for now

kdzwinel · 2017-09-13T22:27:06Z

I have a first version of this audit which:

fails if vieport isn't correctly set

checks if font-size on body >= 16px (original "Success condition")

Couple of questions:

I had to rework the failure description so that the value of the font-size found is at the end. It doesn't work well for the viewport case though (see the screenshot - "found: "). Any ideas how to work around it?
<body> font-size >= 16px fails for google.com (13px), amazon.com (15px), facebook.com (14px) - should we lower the threshold? Or maybe find all failing elements instead of focusing on <body> (as Paul suggested)?

rviscomi · 2017-09-14T04:27:01Z

I was thinking that the entire <body> font-size {#} px (target: >= 16 px) text could be the displayValue, with the detected font size embedded in it. That way it could be included only when it makes sense.

Interesting that those big sites fail the audit. I think the advice is still valid and we shouldn't necessarily lower the bar. I'm open to changing it up so it's not all about the <body>. My suggestion earlier was to have a limit like 90+% of text must be at least 16px. It'd also be nice if it was based on string length (what the user can actually see) rather than element count.

Rough outline of how it could work:

use a tree walker to get all text nodes
map text nodes to font sizes (getComputedStyle(text.parentElement)['font-size']) and text lengths
reduce to the % >= 16px
fail if % < 90

rviscomi · 2017-09-14T05:31:50Z

I couldn't resist making a proof of concept.

const textNodes = [];
const walker = document.createTreeWalker(document.body, NodeFilter.SHOW_TEXT, null, false);
let node;
while(node = walker.nextNode()) textNodes.push(node);

const {valid, total} = textNodes.filter(textNode => {
    return textNode.parentElement
}).map(textNode => {
    return {
        length: textNode.textContent.trim().length,
        fontSize: parseInt(getComputedStyle(textNode.parentElement)["font-size"])
    };
}).reduce((soFar, {length, fontSize}) => {
    soFar.total += length;
    if (fontSize >= 16) soFar.valid += length;
    return soFar;
}, {
    total: 0,
    valid: 0
});

console.log('Percent valid (>=16px):', (valid/total).toFixed(2))

For example, https://mobile.nytimes.com is 85% valid. MDN is 77% valid. Gmail is actually <1% on mobile but 90% on desktop.......

Maybe based on those tests, the passing threshold could even be 75%.

kdzwinel · 2017-09-14T07:47:54Z

SGTM! Also, awesome POC - I didn't know about the treeWalker API.

How about making this audit non-binary and associating a score depending on the % of text < 16px?

kdzwinel · 2017-09-16T14:58:34Z

After some experiments I propose couple of improvements:

use getElementsInDocument helper from dom-helpers as it pierces through shadow DOM
trim value of the text nodes, as there is usually a lot of formatting whitespace between the tags in HTML
use existing table component (as shown below) to list all nodes with illegible text (two columns: selector/xpath and font size in px). Sort the results so that smallest text is at the top.

I've been also thinking about excluding text which is not visible - e.g. because in RWD a lot of text that is visible for desktop gets hidden on mobile via media queries. This might be tricky to get right though (besides display:none and visibility:hidden there is also text-indent, opacity, transforms etc. itd.). @rviscomi WDYT?

rviscomi · 2017-09-17T03:46:59Z

Do you have a link to docs on getElementsInDocument? Curious to learn more about it but it's not appearing in search results.

A table sounds like a good addition. A couple of things to watch out for:

There may be thousands of text nodes and some kind of truncation would be needed.
Users might get the impression that the way to remediate the audit is to focus on each individual span and tweak its font size. The underlying issue is the style rule that affects hundreds of elements, so a table of the most influential font-size rules would go a long way.

Invisible text sounds like a good edge case. I'm inclined to note the caveat in the docs and iterate on it later. Have you looked into testing for visibility with the Intersection Observer API? Not sure if that'll be too slow at this scale.

kdzwinel · 2017-09-17T14:34:32Z

Do you have a link to docs on getElementsInDocument?

Sure, getElementsInDocument is a build-in lighthouse helper:

https://github.com/GoogleChrome/lighthouse/blob/master/lighthouse-core/lib/dom-helpers.js#L20

There may be thousands of text nodes and some kind of truncation would be needed.

Good point, although as far as I can see, existing audits don't have any truncation/pagination (even though they show a lot of results):

It might be a good general feature for the table to add pagination.

table of the most influential font-size rules

Yeah, that'd be much more useful. I've tried getting that information using web APIs (getMatchedCSSRules / getComputedStyles), but it'd be hard/impossible to get that right. Thankfully, we have access to the DevTools Protocol and we can call getMatchedStylesForNode. This will probably require to dump the whole getElementsInDocument solution and do everything using DevTools Protocol. I'll work on that.

Have you looked into testing for visibility with the Intersection Observer API?

Intersection Observer will work for display:none and position:absolute, but won't work for transforms, text-indent and opacity (but maybe that's good enough?). It also limited to the current viewport (but we can always resize the viewport). Not sure about the performance either, but we can try it out in the second iteration 👍

rviscomi · 2017-09-18T02:27:52Z

Oooh getMatchedStylesForNode looks promising. Looking forward to seeing it in action.

@patrickhulce do you have any advice for dealing with extra large tables/lists of debug info? Should we explore the pagination route or just truncate?

kdzwinel · 2017-09-18T08:34:44Z

FYI I've got version showing nodes on seo-font-size branch

Yesterday, I started experimenting with getMatchedStylesForNode and it won't be as easy as I thought it will. The thing is, getMatchedStylesForNode gives you all matching rules, but doesn't tell you which rule is the winning one. It's also a bit problematic to get stylesheet URL based on stylesheet ID - there is no method for that in DT protocol, you have to listen to all stylesheets being loaded while page is loading and store ID -> URL relation yourself. Anyway, DevTools are showing that info:

so it's definitely possible (I might even be able to reuse some of their code). It will just take more time than anticipated.

kdzwinel · 2017-09-26T15:04:34Z

FYI I made some progress (these are selectors from CSS rules on the left):

I have to handle inline styles and make these rules clickable so that they open appropriate files in the Sources pane.

rviscomi · 2017-09-26T17:04:44Z

Nice!! Great work!

What order are the selectors in?

kdzwinel · 2017-09-26T17:20:53Z

ATM random but I can sort them either by font size or amount of text affected. WDYT?

rviscomi · 2017-09-26T17:28:20Z

I like sorting by amount of text affected, most first. Could we also have a column for the % of text affected by that rule? That should make it clear how the list is sorted and quantify how big of an impact each rule has.

Would this table be available even when the audit passes, but there are still instances of small text?

kdzwinel · 2017-09-28T15:59:51Z

Updates:

"% of text affected" added,
table sorted by this value,
table shown even if audit passes.

Failure - gmail.com :

Success - brainly.com :

(details are not expanded by default)

paulirish · 2017-09-29T18:30:44Z

I emailed some details and feedback about our implementation off-thread to konrad and rick. :)

kdzwinel · 2017-10-04T13:55:58Z

Update:

inline styles working,
attributes working,
and I'm also exposing location URL + line:column info.

Unfortunately, ATM there is no way to link to resources (#3457) so I've tried exposing everything in a details table. As you can see, we have a bit of information overload now (screenshot was done in a full window, in DT everything will be even more cramped). I propose we drop line + column since:

IMO it's least useful and
ATM it's only accurate in case of an external stylesheet (for inline styles and embedded stylesheets it shows relative, instead of absolute, values, so it'd require some more work to get right).

rviscomi · 2017-10-05T17:59:10Z

After playing with devtools some more, I've refined my idea of the optimal user experience. Rather than linking to the Sources panel to highlight the line of code containing the applicable style, I think the link should go to the Elements panel. This is consistent with how the "Computed" tab works.

Clicking the circled arrow next to "12px" jumps to the "Styles" tab and has a brief yellow highlight behind the font-size style.

I like this experience better for the audit results for a couple of reasons: the familiarity of inspecting styles (inline, stylesheet, etc) on the Elements > Styles panel, and taking the user directly to the place where they could change the font-size to immediately see how it affects the page. This area also includes a link to the resource/line/column in the Sources panel to give an idea of where the change needs to be made to the source code.

Until the ability to link to other panels is fixed, the next best experience IMO would be to provide the resource/line/column information. So there would be 4 columns:

Source
- eg foo.css:10:5
Selector
- eg .f6 or element.style if inline
Coverage
- eg 35.48%
Font Size
- eg 10px

Not sure if the html file would be referenced in the source column only for style blocks or inline styles. If it's not available for whatever reason, it's ok to leave blank.

rviscomi · 2017-10-05T18:07:42Z

To throw another wrench into this audit, one detail that was discussed briefly during the meeting earlier was that legibility is not just dependent on font size but also font family and language. For example, Thai has dense characters so a larger font than usual may be necessary for legibility. There are also some fonts that are only designed for a minimum size, and below that text is hard to read.

I don't think we can algorithmically account for everything, but maybe there are some heuristics we can take away from it. For example, if we detect that the page is a particular language like Thai or Vietnamese, we may want to consider increasing the minimum font size of the audit. Whatever we do, it's important to make sure that the documentation is clear about how the audit works and any differences between pages. That said, the best thing may just be consistency.

We will have a better idea of things when we release the calibration survey, so this is just food for thought now.

kdzwinel · 2017-10-10T21:33:39Z

@rviscomi I got the table to look as you suggested:

(BTW I also discovered that we need to handle <small> - see last element in the table above)

However, the issue is that for inline styles and <font size=1> it doesn't seem to be possible to get corresponding lines/columns (probably because we operate on a DOM, not HTML). Without that, we leave developers with almost nothing (see rows 3 and 4 above). IMO we should either:

show DOM nodes

or group all these inline+attributes rows together and call them e.g. "element.style" (like DevTools do)

rviscomi · 2017-10-10T21:40:48Z

I'm in favor of your first option, although we should keep / (or /index.html or whatever) as the source even if we don't have line/column and show the nodes under the selector column. I also like the idea of keeping them on separate rows to have finer granularity.

bennidhamma · 2018-06-21T03:46:03Z

The original link in the help text "Use Legible Font Sizes" points to the URL

https://developers.google.com/speed/docs/insights/UseLegibleFontSizes

but now it points to this url:

https://developers.google.com/web/fundamentals/design-and-ux/responsive/#optimize_text_for_reading

Material Design's guidelines state that 14sp (which AFAICT maps to 14px) is the recommended size for paragraph text:

https://learnui.design/blog/android-material-design-font-size-guidelines.html

This feels inconsistent and we're not sure which guideline to follow. We don't want to get scored for search result position, but we also agree with the Material Design guidelines that 14sp/px is actually a more optimal size for paragraph text.

Would you consider changing this audit rule to 14px instead of 16px? Or perhaps provide an explanation or any insight and help clear up our confusion?

thanks!

bennidhamma · 2018-06-21T03:49:50Z

Sorry, I didn't realize the material link was a third party analysis. This link: https://material.io/design/typography/the-type-system.html#type-scale shows a few of the sizes in the type scale at 14, specifically Body2 and Subtitle2 and BUTTON.

Still confused, this audit seems to contradict the recommendations of the Material Design type scale...

rviscomi · 2018-06-21T10:37:48Z

This audit has since been adjusted to recommend at least 12px font 60% of the time. Still not in sync with the MD guideline you cited but more permissive.

bennidhamma · 2018-06-21T14:25:54Z

That's great, thanks!

…

On Thu, Jun 21, 2018, 03:38 Rick Viscomi ***@***.***> wrote: This audit has since been adjusted to recommend at least 12px font 60% of the time. Still not in sync with the MD guideline you cited but more permissive. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3174 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAS6MEfPvU0W-RsUTV03m_Y3sxqfDJOmks5t-3eOgaJpZM4PGTwV> .

rviscomi mentioned this issue Aug 29, 2017

[SEO Audits] Mobile friendly group #3116

Closed

2 tasks

rviscomi changed the title ~~[SEO Audit] Avoids small font sizes~~ [SEO Audits] Avoids small font sizes Aug 29, 2017

patrickhulce added this to the SEO health-check audits milestone Aug 29, 2017

ebidel assigned kdzwinel Sep 5, 2017

rviscomi changed the title ~~[SEO Audits] Avoids small font sizes~~ [SEO Audits] Document avoids small font sizes Sep 6, 2017

rviscomi changed the title ~~[SEO Audits] Document avoids small font sizes~~ [SEO Audits] Document uses legible font sizes Sep 12, 2017

patrickhulce added the needs-priority label Sep 26, 2017

paulirish added the new_audit label Sep 27, 2017

rviscomi added P1 and removed needs-priority labels Sep 29, 2017

paulirish added the seo label Oct 2, 2017

paulirish modified the milestones: SEO health-check audits, Sprint Uno: Oct 2-13 Oct 2, 2017

kdzwinel mentioned this issue Oct 11, 2017

new_audit(font-size-audit): legible font sizes audit #3533

Merged

paulirish modified the milestones: Sprint Uno: Oct 2-13, Sprint Dos: Oct 16-27 Oct 16, 2017

rviscomi modified the milestones: Sprint Dos: Oct 16-27, Sprint Tres: Oct 30 - Nov 12 Oct 30, 2017

vinamratasingal-zz modified the milestones: Sprint Tres: Oct 30 - Nov 12, Sprint Quatro: November 13-26 Nov 13, 2017

rviscomi modified the milestones: Sprint Quatro: November 13-26, Sprint Cinco: November 28 - Dec 9 Nov 27, 2017

vinamratasingal-zz modified the milestones: Sprint Cinco: November 28 - Dec 9, Sprint Seis: December 11 - 22 Dec 11, 2017

rviscomi closed this as completed Dec 14, 2017

paulcpederson mentioned this issue Mar 13, 2018

Consider reducing default font size to 15px/16px Esri/calcite-web#889

Closed

ghost mentioned this issue Jun 27, 2018

Re-Code The CSS for The Banner and Cookie Manager OFFLINE-GmbH/oc-gdpr-plugin#26

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[SEO Audits] Document uses legible font sizes #3174

[SEO Audits] Document uses legible font sizes #3174

rviscomi commented Aug 29, 2017 •

edited

Loading

paulirish commented Aug 30, 2017

rviscomi commented Aug 31, 2017

kdzwinel commented Sep 10, 2017 •

edited

Loading

patrickhulce commented Sep 11, 2017

rviscomi commented Sep 11, 2017

patrickhulce commented Sep 11, 2017 •

edited

Loading

rviscomi commented Sep 11, 2017

kdzwinel commented Sep 13, 2017

patrickhulce commented Sep 13, 2017

kdzwinel commented Sep 13, 2017

rviscomi commented Sep 14, 2017 •

edited

Loading

rviscomi commented Sep 14, 2017

kdzwinel commented Sep 14, 2017

kdzwinel commented Sep 16, 2017

rviscomi commented Sep 17, 2017

kdzwinel commented Sep 17, 2017

rviscomi commented Sep 18, 2017

kdzwinel commented Sep 18, 2017

kdzwinel commented Sep 26, 2017 •

edited

Loading

rviscomi commented Sep 26, 2017

kdzwinel commented Sep 26, 2017

rviscomi commented Sep 26, 2017

kdzwinel commented Sep 28, 2017

paulirish commented Sep 29, 2017

kdzwinel commented Oct 4, 2017

rviscomi commented Oct 5, 2017

rviscomi commented Oct 5, 2017

kdzwinel commented Oct 10, 2017

rviscomi commented Oct 10, 2017 •

edited

Loading

bennidhamma commented Jun 21, 2018

bennidhamma commented Jun 21, 2018

rviscomi commented Jun 21, 2018

bennidhamma commented Jun 21, 2018 via email

[SEO Audits] Document uses legible font sizes #3174

[SEO Audits] Document uses legible font sizes #3174

Comments

rviscomi commented Aug 29, 2017 • edited Loading

paulirish commented Aug 30, 2017

rviscomi commented Aug 31, 2017

kdzwinel commented Sep 10, 2017 • edited Loading

patrickhulce commented Sep 11, 2017

rviscomi commented Sep 11, 2017

patrickhulce commented Sep 11, 2017 • edited Loading

rviscomi commented Sep 11, 2017

kdzwinel commented Sep 13, 2017

patrickhulce commented Sep 13, 2017

kdzwinel commented Sep 13, 2017

rviscomi commented Sep 14, 2017 • edited Loading

rviscomi commented Sep 14, 2017

kdzwinel commented Sep 14, 2017

kdzwinel commented Sep 16, 2017

rviscomi commented Sep 17, 2017

kdzwinel commented Sep 17, 2017

rviscomi commented Sep 18, 2017

kdzwinel commented Sep 18, 2017

kdzwinel commented Sep 26, 2017 • edited Loading

rviscomi commented Sep 26, 2017

kdzwinel commented Sep 26, 2017

rviscomi commented Sep 26, 2017

kdzwinel commented Sep 28, 2017

paulirish commented Sep 29, 2017

kdzwinel commented Oct 4, 2017

rviscomi commented Oct 5, 2017

rviscomi commented Oct 5, 2017

kdzwinel commented Oct 10, 2017

rviscomi commented Oct 10, 2017 • edited Loading

bennidhamma commented Jun 21, 2018

bennidhamma commented Jun 21, 2018

rviscomi commented Jun 21, 2018

bennidhamma commented Jun 21, 2018 via email

rviscomi commented Aug 29, 2017 •

edited

Loading

kdzwinel commented Sep 10, 2017 •

edited

Loading

patrickhulce commented Sep 11, 2017 •

edited

Loading

rviscomi commented Sep 14, 2017 •

edited

Loading

kdzwinel commented Sep 26, 2017 •

edited

Loading

rviscomi commented Oct 10, 2017 •

edited

Loading