Open Bug 859568 Opened 12 years ago Updated 6 years ago

Paragraph font size should match user-preferred font size

Categories

(www.mozilla.org :: Pages & Content, defect, P2)

Tracking

(Not tracked)

People

(Reporter: bugzilla, Unassigned)

References

()

Details

(Keywords: access)

Attachments

(2 files)

The most reliable way to honor and to respect users' preferred font size for legibility/readability is to set it to 100% (or to 1em or to medium or even not to set it at all). Actual results: several mozilla.org stylesheets currently set font-size to 12px or 13px or 14px or small (reserved keyword) or at 90% of the users' preferred font size Example given: https://wiki.mozilla.org/Accessibility uses the following: body { color: #444; font: 90% Arial, sans-serif; } found at the stylesheet https://wiki.mozilla.org/extensions/gmo/skins/gmo/style/screen.css at line 4 Example given: https://quality.mozilla.org/teams/web-qa/ uses the following: body { background: #fff; font: 13px/1.538 Georgia, Times, serif; color: #333; padding-top: 0 !important; } found at the stylesheet https://quality.mozilla.org/qmo_content/themes/QMO4/style.css at line 46 Example given: https://bugzilla.mozilla.org/skins/standard/global.css?1361965956 declares at line 26 /* global (begin) */ body { font-family: sans-serif; color: #000; background: #fff url("global/body-back.gif") repeat-x; } body, td, th, input { font-family: Verdana, sans-serif; font-size: small; } /* monospace is much smaller than Verdana by default, so we make it a bit bigger. */ pre, code, kbd { font-size: medium; } /* global (end) */ access keyword added blocking bug 225639 +CC: Fantasai, Felix Miata, Andrei Hajdukewycz, John Slater
Example given: https://developer.mozilla.org/en-US/ uses the following: body { font: 14px/1.286 "Lucida Grande","Lucida Sans Unicode","DejaVu Sans",Lucida,Arial,Helvetica,sans-serif; } #home-news .hfeed { font-size: 0.857em; } found at the minified stylesheet http://mozorg.cdn.mozilla.net/media/css/tabzilla-min.css at line 1 Both rules combined to produce p (<p class="entry-summary"></p>) with font size of 12px When I disable both these rules, I get to read the text in my preferred font size and the page layout does not break. Screenshot available if requested.
Hi, this I cant really understand :) I've been working with a11y for many years but never heard of this rule or recommendation. What happens if a user has a user-preffered font-size of 42px? the thing I can relate to is this. 1.4.4 Resize text: Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html I tried 200% in IE8 on a couple of pages on mozilla.org and it wasn't any major problems on those pages. everything looks big but all the content could be interpreted.
Hi again, I've been thinking, and why I couldn't understand this is because I've always (what i can remember) used css techniques that respects the users preferred font-size. And for the greater mass it will not effect the layout at all but if you've altered the preferred font-size, then it should be respected on mozilla.org.
Proper viewing perspective on a screen with screen density other than 220 DPI requires the image be displayed such that its black rectangles measure 1" and 25.4mm wide. To do this in a Gecko browser, click the image to adjust its width to fit the viewport, then adjust the widow width until Gecko has made the rectangles 1" and 25.4mm wide. (In reply to Isac Lagerblad (:icaaq) from comment #2) > I've been working with a11y for many years but never heard of this rule or > recommendation. What happens if a user has a user-preffered font-size of > 42px? > the thing I can relate to is this. > 1.4.4 Resize text: Except for captions and images of text, text can be > resized without assistive technology up to 200 percent without loss of > content or functionality. > http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html The issue of text sizing in WCAG2 is woefully inadequately addressed. I tried to get it addressed 18 months ago: http://lists.w3.org/Archives/Public/w3c-wai-ig/2011OctDec/0012.html > I tried 200% in IE8 on a couple of pages on mozilla.org and it wasn't any > major problems on those pages. everything looks big but all the content > could be interpreted. As you say, what if the visitor's default is set to 42px? You see, when a user has changed his browser's default size, he in effect has "resized" in advance. He shouldn't need to do it again on every new site he visits. Causing that need is disrespectful, and because of the availability of em, rem and % for CSS sizing, unnecessary. Does 200% mean with respect to a stylist's 'body: 12px' declaration inherited by paragraph text? Or does it mean with respect to the visitor's existing 42px default? On a stylist's display @96 DPI pixel density, his 12px is physically 9pt, while if the visitor's display is 220 DPI, his 42(device)px default is physically 13.75pt, only 14.5% taller than on Firefox as shipped on the stylist's display, but massively larger than the 3.93pt that is 12px @220 DPI.
Proper viewing perspective on a screen with screen density less than 132 DPI requires the image be displayed such that its black rectangles measure 1" and 25.4mm wide. To do this in a Gecko browser, click the image to adjust its width to fit the viewport, then adjust the widow width until Gecko has made the rectangles 1" and 25.4mm wide.
" Avoiding scaling font sizes smaller than the user-agent default (future link) Note: The author won't actually know the font size, but should avoid percentage scaling that results in less than 100% " coming from Advisory Techniques for 1.4.4 - Resize text http://www.w3.org/WAI/WCAG20/quickref/#visual-audio-contrast-scale-tech-optional-head Additional Techniques (Advisory) for 1.4.4 http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html#visual-audio-contrast-scale-76-head
" Accessibility features in Firefox - Make Firefox and web content work for all users Overriding Page Fonts (...) sites may rely on the browser's default fonts. You can set your default fonts by opening the Preferences window, selecting the Content panel, and selecting a default font and size in the Fonts & Colors section. " coming from Accessibility features in Firefox - Make Firefox and web content work for all users Overriding Page Fonts https://support.mozilla.org/en-US/kb/accessibility-features-firefox-make-firefox-and-we#w_overriding-page-fonts That very webpage - explaining how to set default font size - is actually overriding it; it uses the following line 20: html{ font-size:100%; -webkit-text-size-adjust:100%; -ms-text-size-adjust:100% } line 911: body{ border-top:2px solid #686868; color:#484848; font-family:'Open Sans',Arial,Helvetica,sans-serif; font-size:14px; min-width:1000px; text-align:left } found at the minified stylesheet https://support.cdn.mozilla.net/media/css/common-min.css?build=2d945b8 line numbers correspond when un-minifying the stylesheet.
The latest (most recent) Voluntary Product Accessibility Template webpage states the following: " Documentation for features related that augment accessibility exists in the built-in online help system. (...) A specific help topic labeled "Accessibility Features" describes all accessibility features of Firefox, including (...) overriding page fonts, " coming from Voluntary Product Accessibility Template http://www.mozilla.org/en-US/firefox/vpat-3.html#tph1f while its own formatting stylesheet of such documentation on accessibility uses the following: body { font-family: georgia,serif; font-size: 13px; line-height: 1.231; color:#6d7581 } found at line of 238 when un-minifying the stylesheet https://support.cdn.mozilla.net/media/css/common-min.css?build=2d945b8 Such rule is later overriden by #vpat table td, #vpat table th { font-family: verdana, sans-serif; font-size: 11px; padding: 5px; vertical-align: top; } found at line 6 of http://www.mozilla.org/style/covehead/firefox-vpat.css So, the information is displayed at a font-size of 11px in an un-overridable-page-font manner.
" If you come across a site which ignores your browser settings, and as a result is awkward for you to read, I strongly recommend you complain to the owner/webmaster of the site. " Author: Stephen Poley http://www.xs4all.nl/~sbpoley/main/adjust.html ----------- Accessible Web design and consultancy, Syntactic Home page Setting up your browser; 1. Text font and size " (...) Web pages often try to override this size for their body text. The better-designed sites won't do this (...) " http://www.syntacticweb.co.uk/calib.htm ----------- The Wrong Size Fonts Or why not to over-ride the reader's font size http://www.xs4all.nl/~sbpoley/webmatters/fontsize.html ----------- " Browsers allow the user to set a default font size which will be applied to any font that is not given an explicit size by the displayed page. (...) Page designers can scale their fonts relative to this default size. (...) If you do not specify any font size at all (as on the pages you are reading), text will appear in the default size that was selected by the user. " Truth & Consequences of web site design: Font size http://web.archive.org/web/20100710051522/http://pages.prodigy.net/chris_beall/TC/Font%20size.html ----------- " 5. Fixed Font Size CSS style sheets unfortunately give websites the power to disable a Web browser's 'change font size' button and specify a fixed font size. About 95% of the time, this fixed size is tiny , reducing readability significantly for most people over the age of 40. Respect the user's preferences (...) " Top 10 Mistakes in Web Design, January 1, 2011 http://www.nngroup.com/articles/top-10-mistakes-web-design/
" Size: respect the users' preferences, avoid small size for content As a base font size for a document, 1em (or 100%) is equivalent to setting the font size to the user's preference. Many users prefer that designers do this because it means that the text size will follow user preferences. " W3C Quality Assurance Tips for webmasters; Care With Font Size http://www.w3.org/QA/Tips/font-size#goodcss
" The accepted norm by proponents of web accessibility is to set body text size at 100% (or 1em). This equates to the visitor's default text size, whatever that may be, and is known as relative sizing. It is A Good Thing. " Sensible type sizing on the web by Bergamot http://web.archive.org/web/20111116081550/http://www.bergamotus.ws/misc/sensible-css-text-sizing.html
" Generally speaking, anyone who promotes the use of body font-size less than 100% is highly suspicious. Anyone condoning the use of px or pt for body font-size is to be ignored completely. Go from there. " Bergamot, 17Apr2008, c.i.w.a.s
Continuously commenting with quotes from random people on the internet does not make it any more likely that we will act on this request, but it sure does spam the people who are CCed on this bug. Please stop.
(In reply to Andrei Hajdukewycz [:sancus] from comment #13) > Continuously commenting with quotes from random people on the internet does > not make it any more likely that we will act on this request, but it sure > does spam the people who are CCed on this bug. > Please stop. Stopping is not called for. These comments are not made by "random" people, but by people who understand web accessibility and readability, critical components of web site construction and styling that those responsible for Mozilla.org's styling, like most web stylists, have traditionally either not understood, not been aware of, and/or not considered important.
(In reply to Felix Miata from comment #14) > > Stopping is not called for. How exactly do you expect bugs to be fixed if you intentionally attack, aggravate and spam the people who are responsible for doing the work? Let me be honest with you here -- the previous bug you filed was open for TEN YEARS. Because _I_ care about accessibility, I've pushed the team to seriously consider accessibility standards on mozilla.org whereas previously it was not considered relevant, let alone a priority. If it was, your bug wouldn't have remained open for 10 years! I'm 99.99% sure this(particular) bug is a WONTFIX already, but I am doing you and Gerard the favor of leaving it open because we have yet to establish a firm policy on accessibility standards for mozilla.org. They won't be "change every page on mozilla.org to be large fonts, match AAA WCAG contrast ratios, and match every single WCAG and other accessibility standard known to the entire web." Why? Because we aren't spending web developer time to go back and change the design and font on every page added to mozilla.org since 2000 to match accessibility standards. It's simply not possible. We will be talking about accessiblity standards at our team meeting in Toronto this week, and there will likely be further conversations with the design team about altering *some* of our current procedures. It *is* possible that we can substantially improve accessibility on the site going forward. If your goal here is to actually get your bugs fixed, then I suggest you reconsider your approach. We are not dismissing you out of hand, despite your very strong efforts to encourage us to do so. We do actually care about accessibility and about web standards. But you also need to keep in mind that what changes on mozilla.org is not up to you. You don't do the work and you don't make the decisions. You and Gerard have already reopened bugs that were WONTFIXED by the people in charge of the site and even refiled the issue(that's this bug). That's considered spamming bugzilla, and so are these incessant comments. If your intended goal is for all accessibility bugs to be left open, unfixed, for another ten years, you are free to ignore me, John Slater, Jen Bertsch, and the other people who actually work on mozilla.org. If you choose, instead, to listen to us, then it is likely that we can make some big improvements here for both you and the entire community. We *are* listening to you, we simply disagree on the priority level of this issue.
Component: General → Pages & Content
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: