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

jasonjgw commented 7 years ago

I agree with David. If it turns out that you need to restrict the variability in order to provide a reliably testable SC, then the restrictions should be included in the SC – but only after you’ve determined that they’re necessary.

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.

Thank you for your compliance.

alastc commented 7 years ago

NB: Line height doesn't need, and probably shouldn't have, a unit because it inherits from the font size: http://meyerweb.com/eric/thoughts/2006/02/08/unitless-line-heights/

Rather than "override the following layout of the page", I think it should be: "override the text styles of the page", as it isn't layout per-se (in this one).

I'd rather avoid the mechanism language, as it diverts attention from where the effort should be.

DavidMacDonald commented 7 years ago

We could say:

The following text styles of the page can be overridden with no loss of content or functionality:

But then I think it is more confusing than a mechanism is available. Authors may still think they need to do it and they won't have a definition to click on to tell them they don't. Anyone who will be confused by a Mechanism is available will be confused by many of the WCAG SCs that use that language. It's a fundamental concept in WCAG 2. Incorporating your other suggestions would give us this:

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

(Note: the usual mechanism to achieve this is by a user style sheet or user plugin for the browser.)

lseeman commented 7 years ago

@eadraffan should we add one or two points and get rid of our related SC? Can we add a bullet point to increase space between columns?

DavidMacDonald commented 7 years ago

@eadraffan @lseeman From Issue #51 like this?

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

(Note: the usual mechanism to achieve this is by a user style sheet or user plugin for the browser.)

Authors would pass if they can demonstrate this can be done with at least one test value each. We will provide a plugin or other means to test (like we provided the colour contrast analyser)

WayneEDick commented 7 years ago

Very interesting. The column spacing really influences readability.

Would linearization be enough to meet this?

Are paragraphs enough, or do we need to separate bock level objects.

Wayne

WayneEDick commented 7 years ago

Concerning mechanism.

I think this should be left to techniques. We can suggest CSS and extensions for developers. If they code correctly this will suffice. If they do not code with content-presentation independence then this might not work, in which case the author must produce a mechanism. HTML is a good content because it has a built in mechanism, if authors use it.

For other technologies we will have to describe different techniques. Once again an author is free to implement any technique they wish or not as long as they enable the adaptive choice.

alastc commented 7 years ago

The 'mechanism' language keeps going in and out.

The note helps, but my argument for not having it is that it is misleading on two fronts:

  1. There is a mechanism, that isn't the issue.
  2. It leads people down the 'add a widget' approach.

What's the argument for adding it?

On the addition of "spacing around blocks of text and objects", that means it almost certainly does require an on-screen widget. It takes it up a level, this is no longer "text adaptation", to be about layout adaption as well.

You will struggle to find a non-trivial website where you can increase the column padding without breaking things.

I do not think it is a good idea, it makes it much harder to implement, a separate SC for layout would be better.

GreggVan commented 7 years ago

Hi

The reason for using “mechanism is available” is that it is forward looking and provide future proofing (or future adapting) of SC

Basically it says "if there isnt a mechanism today - - you must provide it. But as soon as AT or browsers provide the function — the requirement on authors automatically goes away."

It should not be used unless there is a real problem that needs to be fixed -and AT and Browsers do not currently fix it.

If you DON’T use “mechanism” then you need to walk away from the problem — or you need to constrain the design of web pages in ways you do not need to with ‘Mechanism” language.

So your choices are use” mechanism is available" limit the design of pages (which is still an option with the mechanism language - but they also have the option of providing the mechanism) walk away from the problem (and hope it is solved someday when the mechanism is provided by AT or browsers)

Which is why we used “mechanism is available” in some WCAG 2.0 SC

Gregg

On Mar 26, 2017, at 5:59 PM, Alastair Campbell notifications@github.com wrote:

The 'mechanism' language keeps going in and out.

The note helps, but my argument for not having it is that it is misleading on two fronts:

There is a mechanism, that isn't the issue. It leads people down the 'add a widget' approach. What's the argument for adding it?

On the addition of "spacing around blocks of text and objects", that means it almost certainly does require an on-screen widget. It takes it up a level https://alastairc.ac/2017/02/four-levels-of-accessibility-customisation/, this is no longer "text adaptation", to be about layout adaption as well.

You will struggle to find a non-trivial website where you can increase the column padding without breaking things.

I do not think it is a good idea, it makes it much harder to implement, a separate SC for layout would be better.

— 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-289319763, or mute the thread https://github.com/notifications/unsubscribe-auth/AJph3hV-NeO19HbSuiJAN7hOvtW57tlHks5rpt-pgaJpZM4LB6K3.

DavidMacDonald commented 7 years ago

Would linearization be enough to meet this?

I agree with @WayneEDick regarding the proposal to add spacing of columns. Linearization accomplishes much the same purpose as requiring space around content, in a different way. I withdraw the proposal to add spacing around blocks and objects.

What's the argument for adding a mechanism is available?

  1. It's consistent with other WCAG 2.0 SC. If people don't know what a mechanism is available means, they will mess up on a lot of WCAG 2.0 or 2.1
  2. It is well defined in WCAG 2.0, so even if it is misunderstood, it can be proven and demonstrated.
  3. If it is not there, the authors may STILL come to the misguided conclusion they have to add a widget for the simple reason that the standard is called "Web Content Accessibility Guidelines" for authors.
  4. If authors misunderstand the the SC without the Mechanism clause, THEN there is no unambiguous normative statement that they can depend on that says they don't need to add a widget.
  5. The proposal says "Note: the usual mechanism to achieve this is by a user style sheet or user plugin for the browser." so that should pastorally address the concern.

Consider

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

vs

A mechanism is available to override the following text styles with no loss of content or functionality:

There is a subtle but critical testing distinction. "Overriding" is passive, the USER is the actor in this phrase, even though they are not mentioned in the passive tense. Any override they try that does not work will cause the author to fail the SC. This will be managed in the understanding doc, but that is not normative and cannot change the meaning of the words in the SC. Unless specific fonts and sizes are laid out, if the user looses functionality on some obscure combination, the author fails. The statement can never be "TRUE" which is a requirement.

Making the "mechanism" the actor of the phrase solves that issue. If the author can demonstrate ONE passing condition for each bullet, she passes. The statement is "TRUE". And we get that without using specific font families.

alastc commented 7 years ago

@GreggVan wrote:

So your choices are

  • use” mechanism is available"
  • limit the design of pages (which is still an option with the mechanism language - but they also have the option of providing the mechanism)
  • walk away from the problem (and hope it is solved someday when the mechanism is provided by AT or browsers)

None of these are valid options for this problem. Take changing font-family as the requirement, and losing font-icons as (one of) the problems:

  1. The mechanism is available (in every browser and common PDF readers).
  2. You don't need to limit the design, you would need to use an alternative technique for the icons such as SVG.
  3. Walking away is not needed or desirable.

Allowing users to over-ride styles is essentially a new thing in WCAG, should we not be open to a new way of describing it? (I know 1.3.1 was a thought to support adaptation, but it has been interpreted in a very screenreader focused way.)

@DavidMacDonald thanks for that, replying to each:

  1. Pretty much everyone who has read that language (including accessibility experts) thinks it means adding a on-page widget, when that isn't the requirement.
  2. It is well defined, but not what is being asked for.
  3. Possibly, but it would be less likely without the mechanism language.
  4. Possibly, but it would be less likely without the mechanism language.
  5. The note helps, but also undermines point of having the mechanism language.

"Overriding" is passive, the USER is the actor in this phrase, even though they are not mentioned in the passive tense.

I'm not sure I understand, there are limits imposed within each bullet point, and tester/ developer is the user when they are the ones overriding the styles. It is the act of over-riding that is important.

Unless specific fonts and sizes are laid out, if the user looses functionality on some obscure combination, the author fails.

Which is why we included fonts/sizes. I think everyone would agree that we need some sort of baseline for testing, it is just where that is specified: In the SC vs the understanding doc. I don't mind either way.

Making the "mechanism" the actor of the phrase solves that issue. If the author can demonstrate ONE passing condition for each bullet, she passes.

The downside is that people are pushed towards creating widgets, and their widgets may not be as useful. For example, their widget might specify a couple of fonts that are not useful to someone with low vision (e.g. narrowly spaced), or a cognitive issue (e.g. not include comic sans as an option).

The fairly narrow 'happy path' for this SC is to ensure that over-riding text aspects doesn't impact content/functionality, which simply means testing it and not using certain techniques.

lauracarlson commented 7 years ago

Hi @mraccess77,

Thank you for your input, Jon. You wrote in GitHub comment 288436745:

@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.

Thanks.

Or maybe we can add it to the first sentence, as we had it in an earlier version.

lauracarlson commented 7 years ago

Hi @GreggVan,

Thank you for your input. You wrote in GitHub comment 288437069

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)

Good idea.

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.

Another good idea.

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"

I meant the metrics that we had in the SC text could be used to create sufficient techniques. For example:

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

  1. font family to Verdana (if it is not already in use)
  2. foreground and background to white on black (if that combination is not already in use)
  3. line spacing to a space-and-a-half within paragraphs, and paragraph spacing to 1.5 times larger than the line spacing.
  4. letter spacing (tracking) to least 0.12 em
  5. word spacing to 0.16em

Expected Results

At the March 21, 2017 AG call @michael-n-cooper said, "... I get the reasoning behind wanting to specify a font but I don't fully agree with it. Understanding materials should recommend testing with a common font. If different fonts yield different results, then the SC is not accomplishing what it wants anyway. I would like to put the precision in the supporting materials."

Gregg, do you agree or disagree with Michael that precision should be in the supporting materials?

Thanks, Laura

lauracarlson commented 7 years ago

Hi @joshueoconnor,

Josh, you wrote in GitHub comment 288437605:

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).

If possible we are going to try not to specify a font in the SC text because on the March 21, 2017 AG call call people had a strong desire to drop the hard metrics for it because of 2 basic concerns:

  1. Internationalization. SC should function for languages other than English.
  2. Verdana is a vendor product.

However, @GreggVan has cautioned in GitHub comment 288441010 to "be sure that the new wording meets all of the SC tests."

I don't know how we will be able to test without values in the SC text. Wayne said it is doable and is working on tests that come out true or false. I'm rooting for him. Go Wayne!

lauracarlson commented 7 years ago

Hi Jason and all,

Thank you for your comment regarding the "either a mechanism exists or no loss of content/functionality" language. Much appreciated.

We had strong push back early in the comments while discussing this SC for authors to not have to provide a mechanism (widget) for mobile. Check as Patrick's 268001666 comment and his 268626340 comment from last December. Also Mike's January 5, 270822241 comment.

Then on the January 5, 2016 LVTF call we discussed having an exception for UAs that do not provide a way to override these items. We agreed that if the user-agent did not have a way (such as mobile does not currently allow user style sheets), authors would be exempt. Authors would be responsible for where it is indeed feasible such as HTML on desktops. Lots of low vision folks can't do things on mobile but having this SC where it is accessibility supported via user stylesheets would be a big benefit.

So at one point we had added a note that read "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."

However, on the March 14, 2017 survey @bruce-usab pointed out that "the NOTE belongs to Accessibility Supported, and is harmful if left with with SC (because then it would be poking Accessibility Supported in the eye)."

Any ideas how we deal with the fact that by default the majority of mobile doesn't support this SC and we have strong opposition to creating mechanisms (widgets) for it?

Thanks, Laura

lauracarlson commented 7 years ago

Hi @GreggVan ,

Gregg, you asked in GitHub comment 288441010

Will this work with all technologies and content types?

Unfortunately no.

As discussed previously in GitHub comment 289431555 it doesn't work on mobile.

lauracarlson commented 7 years ago

Hi @alastc ,

You wrote in GitHub comment 288447400:

Until we resolve that we'll go in circles.

Yes. It seems it is an infinite loop, Alastair. Because the majority of folks seem to want soft metrics for font family and color, perhaps at this point the thing to do is:

  1. Use the soft metrics for font family and color in the SC text for the time being.
  2. Get Wayne's solution and your bookmarklet going to ascertain where problems occur that require hard metrics.
  3. Add hard metrics or a range of hard metrics back to the SC text after data exists to base it on.

Can you live with that approach? It may help halt the circling on the hard/soft metric topic.

lauracarlson commented 7 years ago

Hi David,

@DavidMacDonald asked in GitHub comment 288585205:

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

I agree that this SC has been a tough one. However, user needs do exist. If we can help fill the needs with this SC, I think we should try our best to make it happen.

It is not solely a user agent issue and authors may be able to do some things to help alleviate the problems that Alastair delineated . Thanks again @alastc .

Wayne is working on a solution to test the soft metric SC text that the group preferred at the March 21st meeting. And Alastair provided a bookmarklet for testing.

lauracarlson commented 7 years ago

Hi Jon,

@mraccess77 wrote in GitHub comment 288586976:

@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.

Yes. At its core, the requirement is about authors not creating barriers so users can adapt text.

lauracarlson commented 7 years ago

Hi @alastc ,

Thanks for your GitHub comment 288587151.

I agree. Thank you.

lauracarlson commented 7 years ago

Hi Jason,

@jasonjgw wrote in GitHub comment 288707564:

I agree with David. If it turns out that you need to restrict the variability in order to provide a reliably testable SC, then the restrictions should be included in the SC – but only after you've determined that they're necessary.

Yes. That may help alleviate the chicken and egg situation. We could start out with the soft metrics for font and colors in the SC text and add them back after it is known where problems arise.

Thanks, Laura

alastc commented 7 years ago

As discussed previously in GitHub comment 289431555 it doesn't work on mobile.

Some aspects of it can/will. You can run bookmarklets on mobile quite happily, but anything that requires an extension won't work on iOS. It probably would work (in theory at least) on Android based browsers, but I don't have detailed knowledge on that. The extension would be needed where sites block external scripts (like github).

Mobile devices also have their own version, like Safari's reader mode. It isn't quite the same thing, but it is whether the content supports the change, not the device.

Regarding our loop, I can live with either way but I'd like to minimise repetition as much as possible and get it resolved.

lauracarlson commented 7 years ago

Hi @alastc ,

You wrote in GitHub comment 288755938.

NB: Line height doesn't need, and probably shouldn't have, a unit because it inherits from the font size: http://meyerweb.com/eric/thoughts/2006/02/08/unitless-line-heights/

Is that true for PDF too?

Rather than "override the following layout of the page", I think it should be: "override the text styles of the page", as it isn't layout per-se (in this one).

I'd rather avoid the mechanism language, as it diverts attention from where the effort should be.

Personally I'd rather avoid the mechanism language too. As we know strong push back emerged early in the comments for authors to NOT have to make widgets for this SC.

But I'll go with the consensus of the group.

lauracarlson commented 7 years ago

Hello everyone,

I'd like to see if we can reach consensus on if we should include or not include "A mechanism is available" language for this Adapting Text SC.

@DavidMacDonald thank you for your efforts on this SC. Very much appreciated. You proposed some edits to the SC text in GitHub comment 288852067. Building on this, I offer 2 proposals. They both use soft font-family and color metrics. The proposed approach is to

  1. Use the soft metrics for font family and color in the SC text for the time being.
  2. Get Wayne's solution and Alastair's bookmarklet going to ascertain where problems occur that require hard metrics for font family and color.
  3. Add hard metrics or a range of hard metrics back to the SC text if needed after data exists to base it on.

Proposal A: With mechanism language (27 March 2017)

I have added Gregg's suggestions for a note to address the "at least" language in David's 288852067 edit.

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

font family by at least one different font family text color and background color to at least a single different text color and a single different background color line spacing (leading) to at least 1.5 letter spacing (tracking) to at least 0.12 em word spacing to at least 0.16 em

NOTE: The goal is that pages also work with larger spacing than the minimums cited, but the SC is met if the "at least" value is met.

NOTE: The usual way this is achieved is by a user style sheet or user plugin for the browser.

Proposal B: Without mechanism language (27 March 2017)

This proposal has the same list items but no mention of "mechanism" in the first sentence so attention is not diverted from where author effort should be.

The following text styles of the page can be overridden with no loss of essential content or functionality:

font family by at least one different font family text color and background color to at least a single different text color and a single different background color line spacing (leading) to at least 1.5 letter spacing (tracking) to at least 0.12 em word spacing to at least 0.16 em

NOTE: The goal is that pages also work with larger spacing than the minimums cited, but the SC is met if the "at least" value is met.

NOTE: The usual way this is achieved is by a user style sheet or user plugin for the browser.

Your Action

Please let me know if you cannot live with:

If you have a preference, please let me know that too.

Note: With either A or B we will likely need to do something about mobile because of the strong push back early in this thread to not add widgets. Again, for anyone not aware of the mobile issue please consult the explanation in GitHub comment 289431555.

Also please note: We will need to address Lisa's request to add another bullet point. I will ask Jim to add that topic to a LVTF agenda. So let's table that point for now.

I'll track results on the Consensus Tally for Adapting Text SC Text Wiki page. Let's attempt to get consensus on whether the mechanism language should be in or out of the SC text.

Thanks everyone, Laura

alastc commented 7 years ago

Is that true for PDF too?

Yes, the VIP reader just uses 1.4, 1.5 etc. There is no unit.

It equates to line sizing in things like Word as well, line spacing is "single, 1.5, double" etc, there isn't typically a unit, I'm guessing it is always proportional.

lauracarlson commented 7 years ago

Thanks @alastc. Let's leave it unit-less then.

lauracarlson commented 7 years ago

Hi Lisa,

@lseeman wrote in GitHub comment 288973267:

@eadraffan should we add one or two points and get rid of our related SC? Can we add a bullet point to increase space between columns?

I'll ask on the Low Vision Task Force call what folks think of adding a bullet to add space between columns.

@allanj-uaag could you please add this to the agenda?

Thank you, Laura

DavidMacDonald commented 7 years ago

without hard metrics, I can't live with B, for reasons mentioned. I can explain this on the call. I will bring in the opinion of a lawyer who was a legal draftsman for the Gov of Canada legislation.

“so some combination that is visually discernible to the user”

@GreggVan Hmmm... the user may be blind and no combination will work. Perhaps "differentiated foreground and background colors."

alastc commented 7 years ago

@allanj-uaag Could you include a link to this with that agenda item please? https://alastairc.ac/2017/02/four-levels-of-accessibility-customisation/

That outlines why I think customising layout should be kept separate.

mraccess77 commented 7 years ago

It looks like we will have to address font specifics as without any an author could choose any font change (such as smaller and thinner) and pass the proposed success criteria. Basically unless with specify all the author has to prove is that it can be overwritten with something.

Also for the foreground and background color criteria -- the proposed "discernable" is subjective -- so I'd assume we'd just reference the sufficient contrast requirements for text in SC 1.4.3.

lauracarlson commented 7 years ago

Hi Jon,

You wrote:

It looks like we will have to address font specifics as without any an author could choose any font change

The proposed approach is to

  1. Use the soft metrics for font family and color in the SC text for the time being.
  2. Get Wayne's solution and Alastair's bookmarklet going to ascertain where problems occur that require hard metrics.
  3. Add hard metrics or a range of hard metrics back to the SC text after data exists to base it on.

Can you live with that?

mraccess77 commented 7 years ago

@lauracarlson Yes those soft metrics would be good. I echo the concerns for and against the mechanism is available language -- I like B the best.

DavidMacDonald commented 7 years ago

the proposed "discernable" is subjective -- so I'd assume we'd just reference the sufficient contrast requirements for text in SC 1.4.3.

@mraccess77 This may ofter be for users who want LESS contrast than our minimums, to avoid eye fatigue and triggering etc...

Perhaps

differentiated foreground and background colors

lauracarlson commented 7 years ago

@DavidMacDonald

Good catch. I changed it to, "differentiated foreground and background colors."

Thank you.

alastc commented 7 years ago

Interesting article on changing colours from Gov.uk, includes a good example of issue you can get when changing colours.

lauracarlson commented 7 years ago

I created a Consensus Tally for Adapting Text SC Text Wiki page to track results.

GreggVan commented 7 years ago

what does “differentiated" mean?

how much difference is sufficient to be “differentiable” ?

that is the problem for authors. not knowing what the criteria for success are.

G

On Mar 27, 2017, at 9:33 AM, Laura Carlson notifications@github.com wrote:

@DavidMacDonald https://github.com/DavidMacDonald Good catch. I changed it to, "differentiated foreground and background colors."

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-289454376, or mute the thread https://github.com/notifications/unsubscribe-auth/AJph3nSb9lLKE6o16gFbyBv0uluHdGunks5rp7qmgaJpZM4LB6K3.

lauracarlson commented 7 years ago

The initial color point was that the user can override the color. That was the reason for the white on black hard metric in the current SC. If authors insure white on black, then a person should be able to override to what they need 99% of the time.

GreggVan commented 7 years ago

got it

watch our for this on that on that.

if you have three things over each other — you can’t reduce them to black and white without one of them disappearing.

and be sure to not put words in SC that are not defined or they will bounce in testability test. If they are not important - leave them out. If they can’t be left out — they can’t be ambiguous .

good luck

g

On Mar 27, 2017, at 10:27 AM, Laura Carlson notifications@github.com wrote:

The initial color point was that the user can change the color. That was the reason for the white on black in the current SC. If authors insure white on black, then a person should be able to change to what they need 99% of the time.

— 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-289470445, or mute the thread https://github.com/notifications/unsubscribe-auth/AJph3kSGT51TmT9Kr5VLytvDsdbkfTAxks5rp8dsgaJpZM4LB6K3.

lauracarlson commented 7 years ago

Thanks, Gregg. I'll pull out the word “differentiated" then.

jasonjgw commented 7 years ago

Proposal A has the advantage (to the user) that the author provides the mechanism if there are no user agents or assistive technologies available to do it. However, it seems to me that mechanisms are available already for all of the currently significant technologies (HTML, PDF, etc.), though admittedly not for all devices/environments, and so the author really shouldn't have to intervene to provide the mechanism. The only author responsibility is to ensure that their content incurs no loss when the changes are introduced by the UA. Thus I think Proposal B is fine. Another option would be to introduce Proposal B at level A or AA, and proposal A at level AAA.

WayneEDick commented 7 years ago

Leave "a mechanism" language.

  1. The mechanism concept is well defined in 2.0. Many SCs in 2.0 require developer re-coding.
  2. HTML and PDF support these mechanisms at the user agent level if pages are coded correctly. Thus, a mechanism is present for good code.
  3. If an author does not follow conventions that support independence of content and presentation, then the author should be required to produce a mechanism. That too is consistent with WCAG 2.0 because we do not restrict the author to conforming in just one way. This protects author freedom.
alastc commented 7 years ago

I can live with A if we beef up the note a bit, how about:

NOTE: The usual mechanism is by a user style sheet or user plugin for the browser, so for mark-up languages the authoring requirement is to ensure adaption works for the criteria specified.

(And just thinking, the "I can live with" sounds very petulant, I just mean that beefing it up wll mitigate the problems of people's perception of the on-screen widget aspect.)

lauracarlson commented 7 years ago

Hi @DavidMacDonald , @WayneEDick , @mraccess77 , @jasonjgw , @alastc , and all,

Thanks to all who have responded so far and indicating what you can or can't live with as well as your preferences.

Per @alastc's request - so he can live with proposal A - does anyone object to changing the note from:

NOTE: The usual way this is achieved is by a user style sheet or user plugin for the browser.

and strengthening it to read:

NOTE: The usual mechanism is by a user style sheet or user plugin for the browser, so for mark-up languages the authoring requirement is to ensure adaption works for the criteria specified.

Thanks, Laura

WayneEDick commented 7 years ago

NOTE: The usual mechanism is by a [personalized style declaration (e.g a user style sheet)] or user plugin for the browser [/ media player]. For mark-up languages the authoring requirement is to ensure adaption works for the criteria specified.

I would suggest the above insertion indicated by brackets for technology independence. Although I'm not wedded to the idea. We really don't care if the author comes up with another way to meet this criterion.

alastc commented 7 years ago

That's a good suggestion. I would care a bit if the author has to invent something because you'd be restricted to their implementation, and their font/colour/spacing choices might not be as good or as flexible as yours! I'd try and discourage that approach if possible...

jasonjgw commented 7 years ago

I would support option A with a note along the lines suggested.

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.

Thank you for your compliance.

DavidMacDonald commented 7 years ago

I like the direction, almost there.

I'm nervous changes to the note adds to the requirements, which currently are to simply demonstrate one example over ride for each bullet. The purpose of the note is to provide simple lay language to help the author understand they don't have to create a widget. I think "personalized style declaration" is cryptic and will muddy that message for Johnny lunch box dev. How about something like this?

NOTE: In markup languages, the usual mechanism is a user style sheet or browser plugin provided by the user. In PDF, its a User Agent with style adjustments. The goal is that content doesn't interfere with these adaptations or lose information/functionality in the process.

I'm nervous about saying much more than something like that, for fear it might be perceived to widen the author's responsibility to make it work in all kinds of combinations.

lauracarlson commented 7 years ago

@DavidMacDonald wrote:

NOTE: In markup languages, the usual mechanism is a user style sheet or browser plugin provided by the user. In PDF, its a User Agent with style adjustments. The goal is that content doesn't interfere with these adaptations or lose information/functionality in the process.

Thanks, David.

Can anyone not live with that added as the note?

@alastc can you live with Proposal A, if we add this new verbiage as the note?

Thank everyone, Laura

GreggVan commented 7 years ago

these look like Understanding WCAG comments — or they look like techniques. this should not be in the guidelines doc itself.

g

On Mar 28, 2017, at 8:46 AM, Laura Carlson notifications@github.com wrote:

@DavidMacDonald https://github.com/DavidMacDonald wrote:

NOTE: In markup languages, the usual mechanism is a user style sheet or browser plugin provided by the user. In PDF, its a User Agent with style adjustments. The goal is that content doesn't interfere with these adaptations or lose information/functionality in the process.

Thanks, David.

Can anyone not live with that added as the note?

@alastc https://github.com/alastc can you live with Proposal A, if we add this new verbiage as the note?

Thank everyone, Laura

— 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-289758092, or mute the thread https://github.com/notifications/unsubscribe-auth/AJph3va8v0pAOvPRjO-y5abtHWwWVrGjks5rqQEcgaJpZM4LB6K3.