Font
SC Shortname
Font Family
SC Text
The user can change the font family down to the element level, to any font family available to the user agent with the following exception.
If no mechanism exists to change font family on any user agent for the target technology, then the author is not responsible to create one.
(See Note 1 in Description below)
Suggested Priority Level
Level A
Related Glossary additions or changes
none
What Principle and Guideline the SC falls within.
Principle 1, Guideline 1.4
Description
Simply Put: You can choose the font you need for reading and finding buttons.
Note 1: The document author has no responsibility to create a mechanism to change the font-family. However, if there is a user agent on one of the technologies that has a mechanism to enable user choice of font-family, then the author should do nothing to block that technology.
Example 1: In many browsers on laptops and desktops, one can override the author's font-family based on the categories: serif, sans-serif and monospace. This is not always the case for mobile version of the browser.
Example 2: One can use an extension to change font-family for many browsers. The author should not block this.
Example 3: One can create a browser extension to change font-family.
Need Help: We do not know how web components will effect this. Any help.
Benefits
Some fonts/typefaces are more readable than others, but the needed font varies with the individual. There is a wide split regarding serif or sans serif, but no agreement. Even within san-serif there are are those who prefer Tahoma to Verdana because of spacing differences. Most prefer either of the above to Arial because Arial makes it hard to distinguish between capital I, lower case l, and the digit 1.
Since italic text is often difficult to read with low vision, a different font family, can be a good way to distinguish italicized text and make it readable. This really helps when whole pages are italicized.
Access must be provided at the element level so that users can choose font family identify different element types in the document semantics.
Source: Accessibility Requirements for People with Low Vision, Section 3.3.2
Testability
Will provide JavaScript to implement this test.
Techniques
Existing Relevant Techniques
- G115 Using semantic elements to mark up structure AND H49: Using semantic markup to mark emphasized or special text (HTML)
- G140: Separating information and structure from presentation to enable different presentations
- SCR21: Using functions of the Document Object Model (DOM) to add content to a page (Scripting)
- C22: Using CSS to control visual presentation of text (CSS)
- G141: Organizing a page using headings
- F2: Failure of Success Criterion 1.3.1 due to using changes in text presentation to convey information without using the appropriate markup or text
- F42: Failure of Success Criteria 1.3.1, 2.1.1, 2.1.3, or 4.1.2 when emulating links
- F43: Failure of Success Criterion 1.3.1 due to using structural markup in a way that does not represent relationships in the content
- F46: Failure of Success Criterion 1.3.1 due to using th elements, caption elements, or non-empty summary attributes in layout tables
- F46: Failure of Success Criterion 1.3.1 due to using th elements, caption elements, or non-empty summary attributes in layout tables
- F91: Failure of Success Criterion 1.3.1 for not correctly marking up table headers
New Techniques
- Never use !important for inline settings of font-family
Note: this may be a failure because it prevents adding an <style> element as the last element of the <head> to set default font families that meet user needs.
Related Information
Actions
- Action-70 Write Font SC - on Wayne Dick, August 25, 2016
- Re: Tracking Success Criteria Progress - Erich Manser, 14 September 2016
- Re: lvtf-ACTION-70: Write font sc Wayne Dick, 5 September 2016
- Requirements doc - Alastair Campbell, 18 February 2016
GitHub
- WCAG WG 2.1 GitHub Issue 73 - Opened by Jim Allan, 1 December 2016
Minutes
Resolution
- Ready for WCAG - 1 December 2016