ACTION-347 - Write IER for 1.4.2 Preserving Size Distinctions

Hi! Per ACTION-347, here is proposed expanded version of the IER for 1.4.2 Preserving Size Distinctions (formerly 3.6.2 Preserve Distinctions). The Intent paragraph has been rewritten, the existing (Lee) example reworded slightly for clarity, and a new  (Alessio) example added. I also propose adding the word "whether" to the parenthetical example in the SC itself to improve clarity. However, I'm leery of using the original Lee example, as I don't know of any browsers that support that approach, so I've added a second, reworked version which is supported by most browsers.

    1.4.2 Preserving Size Distinctions: The user can specify whether or not distinctions in the size of rendered text are preserved when that text is rescaled (e.g. whether headers continue to be larger than body text). (Level A)

    Intent:

    The relative size of text provides visual cues that help in understanding and navigating web content, such as when headings are in larger font than body text. This is particularly important because some content may be authored in a way that would make it difficult or impossible to understand if font distinctions were hidden. In these cases, users who set preferences to enlarge or reduce the text size need to have these visual cues preserved. On the other extreme, some users need to have all text rendered in a very specific font size in order for it to be legible. In these cases, the user needs to be able to override author-specified sizes as well as user agent defaults, reducing all text to a single size, even if this may make the structure of some content more difficult to understand, this is preferable than not being able to read it at all.

    Examples:

    *    Lee has moderately low vision and finds text easiest to read at 16 pt Palatino. She chooses to have her browser display all in the Palatino font and at least 16 pt in size. Headlines remain proportionately larger than the body text (e.g. 24 pt and higher) in order to preserve headline prominence, allowing her to both distinguish headings and locate them easily on the screen.

    OR

    *    Lee has moderately low vision and finds text easiest to read at 16 pt Palatino. When viewing a page she presses the Ctrl+Plus keyboard shortcut to enlarge the content until body text is 16 pt tall. Headlines remain proportionately larger than the body text (e.g. 24 pt and higher) in order to preserve headline prominence, allowing her to both distinguish headings and locate them easily on the screen.

    *    Alessio has very low vision and needs to use a screen magnifier at extreme settings, where a single character takes up the entire screen height. If the text size on the screen varied, some letters would be considerably taller than the screen, making them indistinguishable. Therefore he adjusts his browser settings so that all rendered text is exactly the same height as the menus and other user interface elements, and tunes his magnifier settings to for that font size.

For future reference, here is the existing text:

    1.4.2 Preserving Size Distinctions: The user can specify whether or not distinctions in the size of rendered text are preserved when that text is rescaled (e.g. headers continue to be larger than body text). (Level A)

    Intent of Success Criterion 1.4.2:

           The relative size of text provides visual cues that help in understanding and navigating web content and because some content may be authored in a way that would make it difficult or impossible to understand when if font distinctions were hidden. For example, headlines in a larger font than the body text. Users who set preferences to enlarge or reduce the text size need to have these visual cues preserved.

    Examples of Success Criterion 1.4.2:

    *    Lee finds text easiest to read at 16 pt Palatino, but can chooses to have her browser display all in the Palatino font and at least 16 pt in size. She needs the headlines to scale proportionally (e.g. 24 pt) in order to preserve headline prominence.


     Thanks,
     Greg

Received on Wednesday, 30 November 2011 06:47:58 UTC