search

w3c / wcag21

Repository used during WCAG 2.1 development. New issues, Technique ideas, and comments should be filed at the WCAG repository at https://github.com/w3c/wcag.
https://w3c.github.io/wcag/21/guidelines/
Other
140 stars 55 forks source link

Adapting text #78

Closed allanj-uaag closed 7 years ago

allanj-uaag commented 7 years ago

Current versions of SC and Definitions

Open Issues and Survey Results

(Links to surveys require W3C Member access)

SC Shortname

Adapting text

Note: This SC merges 79 Font Family, 78 Spacing, and 74 Text Color as they are very similar in aim (ability to override and adapt text).

SC Text

If the technologies being used allow the user agent to adapt style properties of text, then no loss of essential content or functionality occurs by adapting all of the following:

  1. line height (line spacing) to at least 1.5 times the font size
  2. spacing underneath paragraphs to at least 2 times the font size
  3. letter spacing (tracking) to at least 0.12 times the font size
  4. word spacing to at least 0.16 times the font size

Note: Examples of text that are typically not affected by style properties are open captions and images of text, which are not expected to adapt.

Editor's note: The Working Group seeks to include overriding text color, background color, and font-family as part of this SC, but is not yet able to identify a way to do so that is sufficiently testable.

Suggested Priority Level

Level AA

Related Glossary additions or changes

adapted
Formatting being overridden by the client.
Style Properties
Properties whose values determine the presentation (e.g. font, color, size, location, padding, volume, synthesized speech prosody) of content elements as they are rendered (e.g. onscreen, via loudspeaker, via braille display) by user agents. Style properties can have several origins: * user agent default styles: The default style property values applied in the absence of any author or user styles. Some web content technologies specify a default rendering; others do not. * author styles: Style property values that are set by the author as part of the content (e.g. in-line styles, author style sheets). * user styles: Style property values that are set by the user (e.g. via user agent interface settings, user style sheets).

What Principle and Guideline the SC falls within.

Principle 1, Guideline 1.4

Description

The intent of this Success Criterion is to help ensure that people with low vision can override font family, text colors, and spacing. People with low vision often must override author settings via user stylesheet, bookmarklet, extension or application such as VIP-PDF Reader.

This SC sets metrics for a normative testable values. Any particular user is likely to choose different values (especially font & color).

The principle is that if you override the font (with any font), the issues appear. E.g. font-icons disappear. Same for colors, the act of changing them at all will highlight most or all issues people would get from changing them to their preferred colors.

Line-height, letter-spacing, and word-spacing metrics were chosen as measures based on Research. McLeish ran from .04 to .25 em tests (Wayne E. Dick PhD analyzed the McLeish study and translated from points). McLeish found an increasing curve in reading speed of actual materials up to .25, but it really started to flatten at .20. Previous studies that reported no improvement started at .5em. Right at the flat point. Hence Wayne recommends letter spacing be 0.12em, and word spacing be 0.16em for this SC.

The plan is to start testing sites with these metrics on the various user-agent tools, primarily bookmarklets created specifically for this. See where problems surface. Adjust measures if needed. And then provide techniques.

Benefits

Font Family

Some fonts/typefaces are more readable than others. For example, some people cannot read fonts with sub-pixel rendering...

User Need: Users can change the font face (also called font family or typeface) of all text, choosing from a wide range of fonts including sans serif and serif fonts..

Source: Accessibility Requirements for People with Low Vision, Section 3.3.2

Text Color

...some people need low brightness, especially for backgrounds. Some people, who need low brightness for backgrounds, also need low brightness overall, and thus need low-brightness text.

Other people need high contrast between text and background, including many older people who lose contrast sensitivity from ageing. Some read better with dark text on a light background.

For some people, common color combinations or colors from a limited color palette work fine. For example, black text on a white background, or the inverse, with white text on a black background. Other people need to select more-specific background and text colors. For example, people, who require low brightness overall, need to select the specific background and text colors that provide sufficient contrast for them, yet not too-high brightness. Readable and optimal color combinations differ vastly among individuals, and can even vary from one individual to another, depending upon conditions such as fatigue and lighting.

Figure 8: Web page with author-defined colors with low contrast - light background, gray text, light green headings:

screen capture

Figure 9: Web page with user style with medium contrast - brown background, tan text, headings of different dull colors:

screen capture

Figure 10: Web page with user style with high contrast - black background, white text, headings of different bright colors

screen capture

User Need - Contrast: Users can set the background color and the text color from the full color spectrum.

Source: Accessibility Requirements for People with Low Vision, Section 3.1.2 Text Contrast

Spacing

Spacing such as space between lines and space between words impacts readability.

The space between lines in a block of text is also called leading. Some people need more space between lines to be able to read text. Line spacing also helps with tracking.

User Need: Line Spacing: Users can change the line spacing (leading) for blocks of text.

Source: Accessibility Requirements for People with Low Vision, Section 3.4.1

Some people need more space between letters to read text.

User Need: Letter Spacing: Users can change the letter spacing (space between letters/characters) of blocks of text.

Source: Accessibility Requirements for People with Low Vision, Section 3.4.2

Some people need more space between words to read text.

User Need: Word Spacing: Users can change the word spacing (space between words) of blocks of text.

Source: Accessibility Requirements for People with Low Vision, Section 3.4.3

Testability

Using a bookmarklet, user stylesheet, or VIP-PDF Reader change:

  1. line height (line spacing) to at least 1.5 times the font size
  2. spacing underneath paragraphs to at least 2 times the font size
  3. letter spacing (tracking) to at least 0.12 times the font size
  4. word spacing to at least 0.16 times the font size
  5. font family to a different font family (e.g. Verdana if that is not in use)
  6. foreground color and background color to a different foreground color and background color (e.g. white on black if that combination is not in use)

Expected Results

Techniques

Existing Related Techniques

New Techniques

Related Information

Articles

Public and Member Comments

Research

Tests

Tools

Email

Minutes

GitHub

Wiki Pages

lauracarlson commented 7 years ago

Hello Everyone,

After the discussion on list and in the January 26, 2017 LVTF meeting as well as brainstorming numerous proposals for new SC text to combined issues #79 Font Family, #78 Spacing, and #74 Text Color, @allanj-uaag has updated this SC proposal to do so. Thank you, Jim.

Please review the new merged proposal at the top of this page.

Thoughts and ideas for improvement are most welcome and appreciated.

mbgower commented 7 years ago

Glad these are getting combined. Unless we intend to include stuff other than the styling of text in this SC, "Ability to Override" seems a little non-specific. As some starter suggestions, do any of the following provide a better short name?

lauracarlson commented 7 years ago

Hi @mbgower ,

Thank you very much for your comment and ideas for a new short name for this SC. Rewording to be more specific to text and styling is a good idea, Mike.

@GreggVan mentioned "Ability to Override" in the thread on list and I seem to recall @alastc talking about override prior to that but can't seem to put my finger on that reference at the moment.

Because overriding is the key purpose of the SC I am thinking that the idea of overriding or the word itself probably should be kept. Maybe combine the 2 notions? Would something such as the following work?

@DavidMacDonald had some suggestions for the SC name too.

I've put together a Brainstorming Short Name Ideas for Issue 78 Wiki page to gather all ideas and we can brainstorm them.

Everyone, please add to the list if you have more ideas or I missed any in prior communications.

lauracarlson commented 7 years ago

Hello @mbgower , @DavidMacDonald , @GreggVan , @WayneEDick , @allanj-uaag , @slhenry , @mraccess77 , @patrickhlauke , @alastc , @jnurthen , @goetsu , @bruce-usab , and any one else who is interested ,

We currently have 15 ideas listed on the Brainstorming Short Name Ideas for Issue 78 Wiki page.

Thanks again to @mbgower for suggesting that we make the name more specific. And thanks to everyone for your suggestions.

For a new short name for this SC can anyone not live with any of the names listed?

If you have a preference among them, please let us know that too :-)

awkawk commented 7 years ago

We currently have 15 ideas listed on the Brainstorming Short Name Ideas for Issue 78 Wiki page.

We have "resize text" already in 1.4.4, how about "restyle text"?

lauracarlson commented 7 years ago

Thank you, @awkawk ! I added it to the brainstorming list of possibilities. We are up to 16 proposals now.

lauracarlson commented 7 years ago

Hi @mbgower , @DavidMacDonald , @GreggVan , @WayneEDick , @allanj-uaag , @slhenry , @mraccess77 , @patrickhlauke , @alastc , @jnurthen , @goetsu , @bruce-usab , @awkawk and any one else who is interested ,

The following is line, letter and word spacing research that the LVTF has found so far:

Line Spacing Research: Recommendations for people with low vision, dyslexia, or who are older, range from 1.25 to 2.0. Thanks to @slhenry for all of these.

Letter Spacing Research

Word Spacing Research:

Thoughts on what we should set the SC baseline spacing metrics to?

Thank you!

alastc commented 7 years ago

Hi Laura,

If anyone wants to test this (on sites which aren't Github with a secure-content policy) I updated a bookmark to:

Create a bookmark of any page, and replace the URL with this: javascript:(function()%7Bdocument.body.appendChild(document.createElement(%27script%27)).src%3D%27https://alastairc.ac/tests/layouts/text-adaptation.js%27%3B%7D)()%3B

The BBC makes an interesting test, the layout is fine but the weather icons disappear due to the font-family change.

mbgower commented 7 years ago

@lauracarlson, I can't reach the research from Legge, but suspect s/he did not consider the value of increased letter spacing to improve the target size of controls, which is of possible value. Beyond that, I thought Wayne was going to actually propose values for letter and word spacing. A proposal may focus discussion. Did we ever tackle how images of text or text on an image background fits into the "foreground and background to white on black"?

lauracarlson commented 7 years ago

Hi @alastc,

Thank you for creating the bookmarklet!

I'll create a Wiki page to document results.

lauracarlson commented 7 years ago

Hi @mbgower ,

Gordon Legge didn't discuss increased letter spacing to improve the target size of controls. I agree that would have value.

This is what Legge does say:

Spacing

Spacing has been of interest in studies of low-vision reading because of the crowding phenomenon. Crowding refers to the interfering effects of one target on the identification of a nearby target in the visual field. The spatial extent of crowding increases in peripheral vision (Bouma, 1970), meaning that target stimuli need to be farther apart for recognition. Crowding is a major cause of the reduced visual span in peripheral vision (Pelli et al., 2007; He et al., 2013). Macular degeneration, the leading cause of low vision in the United States, can result in the development of blind spots (scotomas) in central vision extending 5° or more and including the fovea. People with this condition must use peripheral vision for reading. It is reasonable to suspect that increased spacing between letters, words or lines would help their reading by reducing crowding.

Measurements of reading speed for normally sighted subjects have varied letter-letter spacing in a fixed-width font (Courier) from half of standard spacing to twice standard spacing (Chung, 2002; Yu et al., 2007). These studies found that reading speed peaks at the standard spacing. But does extra spacing help in low vision? In a limited experiment, Legge et al. (1985) tested two normal and four low-vision subjects. They read highly magnified text (6° or larger), with normal spacing, and 1.5x and 2x normal spacing. For all of the subjects, reading speed was highest for standard spacing and declined for extra spacing. Chung (2012) conducted a more extensive test with 14 subjects with central-vision loss, and found essentially the same result.

What about interline spacing? Two recent studies with lowvision subjects found either no benefit of extra line separation (Chung et al., 2008) or a very small advantage (Calabrese et al., 2010). But Blackmore-Wright et al. (2013) found that combining double line spacing and double between-word spacing was beneficial for subjects with macular degeneration.

Overall, the evidence indicates that increasing spacing between letters is not helpful, but extra-wide spacing between lines or words may have some benefits for some readers with low vision.

Yes, Wayne has proposed some values. The latest is for letter-spacing. After he read the McLeish study and did some calculations, he proposes 0.1em letter-spacing for the SC.

I agree that a full proposal with the spacing metrics may indeed focus discussion. We just need word spacing now @WayneEDick .

The SC is for text and not images of text so I think we should be okay in that regard. Do we need an explicit disclaimer for that?

Hopefully we can find out about how text on an image background works via Alastair's bookmarklet and its black background. Thanks again Alastair!

mbgower commented 7 years ago

Thanks for sharing those results, @lauracarlson. I'm going to show my age by stating that those findings are not surprising from a historical printing/publishing perspective, since it's been known for some time that kerning needs to be tightened as print size increases to improve readability. There are distinctions between kerning (letter-combination spacing) and tracking (letter-spacing) but I urge that we not confine the letter-spacing guidance to only positive numbers. Some users may benefit from tighter than average spacing, depending on the visual condition they have, especially when the font is very large. So I'd advocate for +/- .1 em, rather than simply + .1 em.

lauracarlson commented 7 years ago

Hi @alastc and all,

I started a Wiki page to document results from Alastair's bookmarklet and added his results to see if that is the data we want to collect. The bookmarklet and wiki page may need to change depending on the metrics we decide on.

allanj-uaag commented 7 years ago

Good point Mike, I like the plus or minus for letter spacing.

On Mon, Feb 6, 2017 at 1:37 PM, Mike Gower notifications@github.com wrote:

Thanks for sharing those results, @lauracarlson https://github.com/lauracarlson. I'm going to show my age by stating that those findings are not surprising from a historical printing/publishing perspective, since it's been known for some time that kerning needs to be tightened as print size increases to improve readability. There are distinctions between kerning (letter-combination spacing) and tracking (letter-spacing) but I urge that we not confine the letter-spacing guidance to only positive numbers. Some users may benefit from tighter than average spacing, depending on the visual condition they have, especially when the font is very large. So I'd advocate for +/- .1 em, rather than simply + .1 em.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/78#issuecomment-277788792, or mute the thread https://github.com/notifications/unsubscribe-auth/AG_WL7HRwt1Fp9VjtCirtvwZM2QMMNuBks5rZ3aHgaJpZM4LB6K3 .

-- Jim Allan, Accessibility Coordinator Texas School for the Blind and Visually Impaired 1100 W. 45th St., Austin, Texas 78756 voice 512.206.9315 fax: 512.206.9264 http://www.tsbvi.edu/ "We shape our tools and thereafter our tools shape us." McLuhan, 1964

alastc commented 7 years ago

Hi @mbgower, I don't think it is necessary to include minus numbers in the spacing aspect because reducing the size doesn't create issues. (Unless I'm missing something?)

These values (verdana/black&white/EMs) are intended to provide a standard baseline, any particular user is likely to choose different values (especially font & colour).

The point is that this baseline is used to test the layout & functionality, and if it works then it is robust enough for certain user-adaptations (up to a point).

If the user reduces the letter or word spacing, it takes less room, there is nothing for the author to do. However, increasing the spacing can cause wrapping or overlap.

It somewhat fits into good practice and internationalisation anyway, but it sets a baseline for accessibility that people an test with.

mbgower commented 7 years ago

@alastc, thanks for the clarification. If you haven't seen any issues from reducing spacing, that's good to know.

lauracarlson commented 7 years ago

Hi @mbgower , @DavidMacDonald , @GreggVan , @WayneEDick , @allanj-uaag , @slhenry , @mraccess77 , @patrickhlauke , @alastc , @jnurthen , @goetsu , @bruce-usab , @awkawk , and any one else who is interested,

@allanj-uaag has updated the SC text at the top of this page per discussion on the February 2, 2017 Low Vision Task Force call. Wayne objected to white on black in the SC text. But said it would be okay in the testability section.

The SC text currently reads:

No loss of content or functionality on a webpage is caused by overriding:

  • font family to Verdana, or
  • foreground and background to a single different foreground color and a single different background color, or
  • line-height of all text to 1.5, letter-spacing to 0.03em, and word-spacing to 0.07em.

Note: If no mechanism exists to override these items on any user agent for the target technology, then the author has no responsibility to create one.

White on black is still in the testability section.

Thoughts? Can anyone not live with that text?

Thank you!

bruce-usab commented 7 years ago

I can live with that text. My preference would be to tie the note more closely to the concept of Accessibility Supported, but I think this works well enough as-is for the first public working draft. I don't have a suggestion for the note phrasing.

lauracarlson commented 7 years ago

Hello @mbgower , @DavidMacDonald , @GreggVan , @WayneEDick , @allanj-uaag , @slhenry , @mraccess77 , @patrickhlauke , @alastc , @jnurthen , @goetsu , @bruce-usab , and any one else who is interested ,

I added "Preferences" and "Names People Can't Live With" sections to the Brainstorming Short Name Ideas for Issue 78 Wiki page. Please add your choices there or let me know here and I will add them.

Thanks Jim for being the first to share your choices.

lauracarlson commented 7 years ago

LVTF Thread: Issue 78 SC text - was Re: Post-Minutes update.

A pull request is available. Please continue any discussion there.

Thanks everyone!

allanj-uaag commented 7 years ago

closed. see issue #124

WayneEDick commented 7 years ago

I think this is a lot easier to implement than the thread indicates. There are very few sites that can't withstand the spacing and font family change. Color is a little harder because people use background-images for holding sprites. This cause icons to disappear.

As far as need is concerned here is the basis.

Many have shown font family influences legibility. It is not the same for everyone, so user choice is needed.

Line spacing has been shown repeatedly to help "tracking". It is very important for eyes that introduce their own noise to have line appearing clear and distinguishable.

The literature on letter spacing is mixed. The difference seems to reside in the testing method. If a drifting text method is used no legibility difference is detected. If text is in a natural usage environment, on a page, there is a measurable difference. Also, the difference decreases past a certain point 0.25 em. The word spacing value was just empirical. CSS already adjusts word spacing with letter spacing, but a little extra bump helps to separate words.

Color access addresses two conflicting needs. People with visual acuity loss have an associated contrast sensitivity loss. This mitigates for higher contrast ratios. Unfortunately many common causes of visual acuity loss like central field loss are also associated with photo-phobia. Giving access to color enables the user to choose color pairs that give maximum contrast with minimum light. Since, color determines contrast and brightness, access to color is the key.

This SC should be Level A in terms of need.

lauracarlson commented 7 years ago

Hi @WayneEDick ,

Thank you for the comment.

However, this issue is closed. Please check @allanj-uaag 's February 13 comment.

A pull request is available. The latest discussion continues there.

But @awkawk also closed that pull request on February 17 so I am not sure where any new comments are supposed to go now.

Andrew, can you please advise? Where should people comment on closed issues whose related pull request has also been closed? Thanks.

WayneEDick commented 7 years ago

People without low vision do not comprehend the impact of little adjustments. I tend to use a smaller letter space than the one in the SC, .06 to .09 em. It helps me sort out the middle of long words. For me color is important because my central retina damage sets me up for photo-phobia. My condition is congenital, but it functions like macular degeneration a very common impairment acquired impairment. WCAG 2.0 didn't take photo-phobia into account. For me a sans serif font that makes it easy to distinguish between l, 1 and I is important for running text.

For me, I can using a smaller font-size with these other adjustments.

Print media was developed for people who reside in the center of the normal distribution of readers. People with low vision live on the outer tails of the normal distribution, three or more standard deviations out. Different rules apply.

These needs might appear trivial to one for whom our print system was invented, but it is a serious need for people outside of that norm. There is good research supporting this need. Look at the LVTF Requirements Document for references. Laura has built an incredible bibliography.

GreggVan commented 7 years ago

+1

Gregg

On Feb 20, 2017, at 10:23 PM, WayneEDick notifications@github.com wrote:

People without low vision do not comprehend the impact of little adjustments. I tend to use a smaller letter space than the one in the SC, .06 to .09 em. It helps me sort out the middle of long words. For me color is important because my central retina damage sets me up for photo-phobia. My condition is congenital, but it functions like macular degeneration a very common impairment acquired impairment. WCAG 2.0 didn't take photo-phobia into account. For me a sans serif font that makes it easy to distinguish between l, 1 and I is important for running text.

For me, I can using a smaller font-size with these other adjustments.

Print media was developed for people who reside in the center of the normal distribution of readers. People with low vision live on the outer tails of the normal distribution, three or more standard deviations out. Different rules apply.

These needs might appear trivial to one for whom our print system was invented, but it is a serious need for people outside of that norm. There is good research supporting this need. Look at the LVTF Requirements Document for references. Laura has built an incredible bibliography.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/78#issuecomment-281235009, or mute the thread https://github.com/notifications/unsubscribe-auth/AJph3oTmZuKrIv7iha5H5Je5NJ0AlQeFks5relisgaJpZM4LB6K3.

WayneEDick commented 7 years ago

So, Laura -

The new Editors Draft points to these threads. I really never could address this list effectively because I couldn't use it. Now I can.

Wayne

On Monday, February 20, 2017, Laura Carlson notifications@github.com wrote:

Hi @WayneEDick ,

Thank you for the comment.

But this issue is closed. Please check @allanj-uaag 's [ https://github.com/w3c/wcag21/issues/78#issuecomment-279514350 February 13 comment].

A pull request is available. The latest discussion continues there.

But @awkawk also closed that pull request on February 17 so I am not sure where any new comments are supposed to go now.

Andrew, can you please advise? Where should people comment on closed issues whose related pull request has also been closed?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

Ryladog commented 7 years ago

+1

​​​​​ katie

Katie Haritos-Shea Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)

Cell: 703-371-5545 | mailto:ryladog@gmail.com ryladog@gmail.com | Oakton, VA | http://www.linkedin.com/in/katieharitosshea/ LinkedIn Profile | Office: 703-371-5545 | https://twitter.com/Ryladog @ryladog

NOTE: The content of this email should be construed to always be an expression of my own personal independent opinion, unless I identify that I am speaking on behalf of Knowbility, as their AC Rep at the W3C - and - that my personal email never expresses the opinion of my employer, Deque Systems.

From: GreggVan [mailto:notifications@github.com] Sent: Monday, February 20, 2017 10:30 PM To: w3c/wcag21 wcag21@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [w3c/wcag21] Ability to Override (was Spacing) - Revised 9 Feb 2017 (#78)

+1

Gregg

On Feb 20, 2017, at 10:23 PM, WayneEDick <notifications@github.com mailto:notifications@github.com > wrote:

People without low vision do not comprehend the impact of little adjustments. I tend to use a smaller letter space than the one in the SC, .06 to .09 em. It helps me sort out the middle of long words. For me color is important because my central retina damage sets me up for photo-phobia. My condition is congenital, but it functions like macular degeneration a very common impairment acquired impairment. WCAG 2.0 didn't take photo-phobia into account. For me a sans serif font that makes it easy to distinguish between l, 1 and I is important for running text.

For me, I can using a smaller font-size with these other adjustments.

Print media was developed for people who reside in the center of the normal distribution of readers. People with low vision live on the outer tails of the normal distribution, three or more standard deviations out. Different rules apply.

These needs might appear trivial to one for whom our print system was invented, but it is a serious need for people outside of that norm. There is good research supporting this need. Look at the LVTF Requirements Document for references. Laura has built an incredible bibliography.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/78#issuecomment-281235009, or mute the thread https://github.com/notifications/unsubscribe-auth/AJph3oTmZuKrIv7iha5H5Je5NJ0AlQeFks5relisgaJpZM4LB6K3.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/78#issuecomment-281235768 , or mute the thread https://github.com/notifications/unsubscribe-auth/AFfqyih1IW03OR_s9FczK-BKvxDemoF2ks5relozgaJpZM4LB6K3 . https://github.com/notifications/beacon/AFfqytpV2KzmilkCFgMKhFORSCBrsz47ks5relozgaJpZM4LB6K3.gif

awkawk commented 7 years ago

Updated the issue description to reflect the FPWD text and reopening issue.

awkawk commented 7 years ago

I think that we need to be careful about naming a font as we run the risk of people building in widgets that allow the font to be changed to Verdana and nothing else.

Similarly I think that we need to generalize the other criteria here also.

alastc commented 7 years ago

We're looping back again, I think we need an FAQ!

I think there is a good argument for specifying the values, otherwise you'll get different results.

The principle is that if you override the font (with any font), the issues appear. E.g. font-icons disappear. Same for colours, the act of changing them at all will highlight most or all issues people would get from changing them to their preferred colours.

We also need to put a limit on the size-different from spacing, otherwise it is a 'piece of string' problem.

awkawk commented 7 years ago

@alastc - ok, so we need to discuss on the call. I'd be inclined to rewrite this like 1.4.8:

A mechanism exists to modify the presentation of textual information, unless overriding the following results in a loss of content or functionality:

Font family can be selected by the user. Foreground and background colors can be selected by the user. Line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing. Letter spacing (tracking) is at least 0.12 em, and word spacing is at least 0.16 em.

lauracarlson commented 7 years ago

@awkawk this issue does not currently have the latest SC text. It is in the pull request. The note was removed. Can you please update it?

Also please check my replies to the February 14, 2017 survey comments.

mraccess77 commented 7 years ago

@awkawk I am concerned with the text "unless overriding the following results in loss of content or functionality". This would basically means no one has to implement this SC. That clause would allow anyone to get out of implementing the SC. For example, if I implement my CSS in a way that prevents the increase of line spacing I don't have to fix it because overriding the spacing in a custom style sheet would cause loss of content or functionality so no need to fix it.

lauracarlson commented 7 years ago

@awkawk Currently the underlying requirement is unfortunately not to allow overriding font, spacing and color to any value desired by the user. Instead it is to allow overriding to specific values due to the SC criteria of testability. The plan is to start testing sites with these metrics on the various user-agent tools, primarily bookmarklets created specifically for this. See where problems surface. Adjust measures if needed. And then provide techniques.

The underlying rationale of the hard-coded metrics approach has been addressed by @alastc . As Alastair has said,

...if it can't be tested true/false from the SC text, it won't meet the SC criteria. You can flesh things out in the understanding doc, but the SC needs to be a true/false statement...If my team tests a page with Verdana and black & white, and another team tests the same page with "Latin Wide" (or some other very differently sized font) and purple and green, we will get different results. Not due to subjectivity, but objectively different results. Given where these SCs are used (including for lawsuits), I think Gregg is right to say we need normative testability. If there were some way to state the requirement without a specific font/color/size value and still have it be testable, that would be great. But it has to be a content requirement, not a user-requirement, and that means specific values.

@WayneEDick has summed up the concern of many in the low vision community with naming specifying hard values [6]. He has said,

If you wonder why the people with low vision are so skeptical of narrow SCs when what we need is flexibility...We know well that normative language is what becomes law. Putting single point conformance in an SC is dangerous. It is the FPWD so let's get it there. If single point normative language is all we can get in 2.1, so be it.

We would all love to change it, if it is possible.

lauracarlson commented 7 years ago

I updated the first comment with the current SC Text as well as added links for SC for viewing, editing and the SC in full draft guideline.

WayneEDick commented 7 years ago

I do not understand this letter. I cannot find any change of text?

Wayne

On Wed, Mar 15, 2017 at 1:57 PM, Laura Carlson notifications@github.com wrote:

I updated the first comment with the current SC Text.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/78#issuecomment-286876725, or mute the thread https://github.com/notifications/unsubscribe-auth/AH0OF5Pt3Rsk9fUNUU3rsiCR7DEYGj3Bks5rmFC2gaJpZM4LB6K3 .

lauracarlson commented 7 years ago

Hi Wayne,

Now that SC managers are able to edit their issues (many thanks to @michael-n-cooper and @awkawk) I updated the first comment so it is accurate and matches the pull request and what is in the First Public Working Draft, 28 February 2017.

For the FPWD we had deleted the note "If no mechanism exists to override these items on any user agent for the target technology, then the author has no responsibility to create one" because @slhenry wanted that removed.

I also added links for SC for viewing, editing and the SC in full draft guideline per Andrew's instructions.

WayneEDick commented 7 years ago

Thank You.

On Thu, Mar 16, 2017 at 4:59 AM, Laura Carlson notifications@github.com wrote:

Hi Wayne,

Now that SC managers are able to edit their issues (many thanks to @michael-n-cooper https://github.com/michael-n-cooper and @awkawk https://github.com/awkawk) I updated the first comment https://github.com/w3c/wcag21/issues/78#issue-192966685 so it is accurate and matches the pull request and what is in the First Public Working Draft, 28 February 2017 https://www.w3.org/TR/2017/WD-WCAG21-20170228#adapting-text.

For the FPWD we had deleted the note "If no mechanism exists to override these items on any user agent for the target technology, then the author has no responsibility to create one" because @slhenry https://github.com/slhenry wanted that removed.

I also added links for SC for viewing, editing and the SC in full draft guideline per Andrew's instructions https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JanMar/1200.html.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/78#issuecomment-287036230, or mute the thread https://github.com/notifications/unsubscribe-auth/AH0OF6DEh3cg-2IeeEIuc4JcKiTLuY7Fks5rmSQtgaJpZM4LB6K3 .

lauracarlson commented 7 years ago

This issue was discussed at the March 21, 2017 AG meeting.

lauracarlson commented 7 years ago

Hello everyone,

After yesterday's discussion, @awkawk 's proposed rewrite and @mraccess77 's concerns what do you think about rewriting the current adapting-text SC, which is:

No loss of content or functionality on a webpage is caused by overriding:

  1. font family to Verdana, or
  2. foreground and background to white on black, or
  3. line height of all text to 1.5, letter spacing to 0.12em, and word spacing to 0.16em.

To read:

Either a mechanism exists to adapt textual information or no loss of content or functionality exists when:

  • font family is overridden by the user.
  • foreground and background colors are overridden by the user.
  • line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing.
  • letter spacing (tracking) is at least 0.12 em, and word spacing is at least 0.16 em.

With this approach the offending hard coded metrics are removed and the understanding and technique documents will have to provide the details.

@patrickhlauke and @DavidMacDonald this does get us back to authors creating mechanisms...just about where we started.

Patrick and David this version incorporates Andrew's suggestion that authors need to create mechanisms (as a last resort)... and just about gets us back to where we started.

Thoughts? Ideas for improvement? Is this getting closer to what people can live with?

Thank you.

mraccess77 commented 7 years ago

@lauracarlson I like the overridden part in the 1st two bullets as it makes clear we are not asking the author to set these settings for all content but for the content to be able to adapt to this if the user sets it. Perhaps we should add the same override language to the other bullets.

GreggVan commented 7 years ago

This is much better a couple suggestions.

Either a mechanism exists to adapt textual information or no loss of content or functionality exists when:

font family is overridden by the user. Good foreground and background colors are overridden by the user . RECOMMENDATION Add to end “so some combination that is visually discernible to the user”
(otherwise it could be argued that if it is black on black it would fail — so how can I assure this) line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing.

letter spacing (tracking) is at least 0.12 em, and word spacing is at least 0.16 em.

Authors may not know what to do with all the “at leasts” do they have to test with more? RECOMMENDATION: Add a note: NOTE: The goal is that pages also work with larger spacings than the minimums cited, but the SC is met if the “at least” value is met.

With this approach the offending hard coded metrics are removed and the understanding and technique documents will have to provide the details

Not sure what you meant by details…Remember you CANNOT add additional details of what is required anywhere else in other materials. They can only give examples (techniques) or explanations (understanding). They cannot define or restrict solutions.

But perhaps that is what you meant. by ‘details"

@patrickhlauke https://github.com/patrickhlauke and @DavidMacDonald https://github.com/DavidMacDonald this does get us back to authors creating mechanisms...just about where we started.

Patrick and David this version incorporates Andrew's suggestion that authors need to create mechanisms (as a last resort)... and just about gets us back to where we started.

Thoughts? Ideas for improvement? Is this getting closer to what people can live with?

Thank you.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/78#issuecomment-288431441, or mute the thread https://github.com/notifications/unsubscribe-auth/AJph3uFs3ICBxMlxWVpfUqdDTUKcX08Dks5roTs_gaJpZM4LB6K3.

joshueoconnor commented 7 years ago

I like @awkawk edit - I'd rather not specify a font - like Verdana (though I understand the reasoning behind why it was picked - Websafe etc).

jasonjgw commented 7 years ago

This latest proposal is evolving in the right direction. I am concerned about the use of "either a mechanism exists or no loss of content/functionality" language. The term "a mechanism is available/exists" has always been meant to entail that the mechanism is either provided by the user agent/assistive technology, or (failing that) by the content author. This latest proposal tends to reinforce the misinterpretation according to which "mechanism is available" is misunderstood as equivalent to "mechanism is provided by the content author".

What you really mean is that a mechanism is available (from the user agent, an assistive technology or the content itself) to adjust these characteristics, and no loss of content/functionality occurs as a result of such changes. I hope this helps to clarify the point. If your testing technique is not sufficiently reliable across the entire range of these variables (all different fonts, etc.), you can put a restriction into the text of the success criterion to a range over which your testing techniques are known to work reliably.

GreggVan commented 7 years ago

oops missed that

I agree

it should be A mechanism exists to adapt textual information where no loss of content or functionality exists when:

otherwise

a mechanism exists to adapt textual information

is completely undefined and untestable. What type of mechanism to do what type of adaptation?

CAUTION - be sure that the new wording meets all of the SC tests. Will this work with all technologies and content types?

greg

On Mar 22, 2017, at 11:37 AM, jasonjgw notifications@github.com wrote:

This latest proposal is evolving in the right direction. I am concerned about the use of "either a mechanism exists or no loss of content/functionality" language. The term "a mechanism is available/exists" has always been meant to entail that the mechanism is either provided by the user agent/assistive technology, or (failing that) by the content author. This latest proposal tends to reinforce the misinterpretation according to which "mechanism is available" is misunderstood as equivalent to "mechanism is provided by the content author".

What you really mean is that a mechanism is available (from the user agent, an assistive technology or the content itself) to adjust these characteristics, and no loss of content/functionality occurs as a result of such changes. I hope this helps to clarify the point. If your testing technique is not sufficiently reliable across the entire range of these variables (all different fonts, etc.), you can put a restriction into the text of the success criterion to a range over which your testing techniques are known to work reliably.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/78#issuecomment-288438967, or mute the thread https://github.com/notifications/unsubscribe-auth/AJph3tgaCjDWqe6egwUKE1w_4M2rXDV3ks5roUA1gaJpZM4LB6K3.

alastc commented 7 years ago

I would argue that a mechanism does exist for most of the aspects already (the browser), and all aspects with scripting / pluggins. The problem is what happens when you employ that mechanism: loss of content/functionality.

What about starting with:

There is no loss of content or functionality when text is adapted by:

However, I think we'll still have testing issues with the value-less bullets because if one person changes a font to Verdana, and another person uses Arial narrow, you will get different results. E.g. text overlaps or wraps out of containers with the larger font.

I note that we still have a disagreement with some people saying (such as) @michael-n-cooper:

I would like to put the precision in the supporting materials.

And @GreggVan saying:

you CANNOT add additional details of what is required anywhere else in other materials. They can only give examples (techniques) or explanations (understanding). They cannot define or restrict solutions.

Until we resolve that we'll go in circles.

DavidMacDonald commented 7 years ago

I've read through the entire thread, and I'm not sure that we're accomplishing much with the SC.

It seems hard to fail this in HTML, and hard to test this, confusing to understand what is required. It just seems to me that this should be punted to Silver, where User Agents are involved. Unless there is an elegant way out of the mess and real momentum from stakeholders responding the FPWD.

I'm interested in what other's opinions might be on this.

mraccess77 commented 7 years ago

@DavidMacDonald Perhaps it's so much about being able to do it as is but about content being cutoff or lost. That is a user agent or extension may allow for you change the CSS but if the text is cut off because the author used a fixed sized container that prevents overflow then there is a real issue.

alastc commented 7 years ago

We've established it SHOULD be a user agent issue, and that user agents SHOULD allow users to do this.

No, we've established that the user-agent has a part to play, but there are things for the author as well.

I'd also say it is fairly easy to test: run a bookmarklet on the page with pre-determined values. What real users might do is rather more "messy" (I think Wayne would say flexible), but we're bringing it into a reasonable-to-test area by using that as a proxy for finding issues. Kind of like keyboard accessibility is a proxy for several user-input devices.

Using that test, you find things like:

That's just from the first few pages, I'm sure we'll find more, and generate quite a few techniques (and perhaps even failures ;-) ).

There is a real user need (adapting text) that currently does not work consistently due to things authors do in HTML/CSS/JS. There is already some external stakeholder support: #153

DavidMacDonald commented 7 years ago

A mechanism is available to override the following layout of the page, with no loss of content or functionality:

I think this wording allows us to get the message across, gets it on the table, alerts browser manufacturers, gives the issue high profile. It does not prescribe the a wide array of requirements for each option on authors. For instance, if the font family can be overridden by any other font, it passes. If the background and foreground colours can be overridden by any other colour, then it passes. I think that is the right balance.