This repository has been archived by the owner. It is now read-only.

Adapting text #78

Closed
allanj-uaag opened this Issue Dec 1, 2016 · 444 comments

Comments

Projects
None yet
@allanj-uaag
Contributor

allanj-uaag commented Dec 1, 2016

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

  • No loss of content or functionality.

Techniques

Existing Related Techniques

New Techniques

  • Allowing for override of spacing (draft technique)
  • Allowing for override of font family (new technique)
  • Allowing for override of text color (future technique)

Related Information

Articles

Public and Member Comments

Research

Tests

Tools

Email

Minutes

GitHub

Wiki Pages

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Dec 15, 2016

Contributor

Signing up as SC Manager for Issue 78.

Contributor

lauracarlson commented Dec 15, 2016

Signing up as SC Manager for Issue 78.

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Dec 19, 2016

Contributor

@DavidMacDonald noted on his spreadsheet that this proposal does not seem to meet the "All Technologies" SC acceptance criteria and that it is "Not Mature User/Agent issue".

Thoughts?

Contributor

lauracarlson commented Dec 19, 2016

@DavidMacDonald noted on his spreadsheet that this proposal does not seem to meet the "All Technologies" SC acceptance criteria and that it is "Not Mature User/Agent issue".

Thoughts?

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Dec 19, 2016

Member

Not all browsers - particularly on mobile/tablet devices - support user stylesheets, and don't provide any browser/OS level controls that are this granular. The only possible solution for an author to meet this SC would then be to implement a complete customisation/personalisation system for their page/site, which is technically non-trivial and onerous (for a AA, and even a AAA). In my opinion, of course.

Member

patrickhlauke commented Dec 19, 2016

Not all browsers - particularly on mobile/tablet devices - support user stylesheets, and don't provide any browser/OS level controls that are this granular. The only possible solution for an author to meet this SC would then be to implement a complete customisation/personalisation system for their page/site, which is technically non-trivial and onerous (for a AA, and even a AAA). In my opinion, of course.

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Dec 19, 2016

Contributor

I think there are a couple from LVTF are are essentially 'passed' when you use HTML based tech, but the idea was to include it to add the requirement other technologies. I believe this is one?

For anyone coming to it fresh it appears to ask for customisation, but that isn't the aim.

It would be useful for Jim or someone more familiar with that to raise it at WCAG level, as I think it is "mature" and tech-neutral, but aimed at non-HTML technologies.

Contributor

alastc commented Dec 19, 2016

I think there are a couple from LVTF are are essentially 'passed' when you use HTML based tech, but the idea was to include it to add the requirement other technologies. I believe this is one?

For anyone coming to it fresh it appears to ask for customisation, but that isn't the aim.

It would be useful for Jim or someone more familiar with that to raise it at WCAG level, as I think it is "mature" and tech-neutral, but aimed at non-HTML technologies.

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Dec 19, 2016

Contributor

My concern is that this really is a User agent issue. I dread the thought of telling large companies to use up prime real estate (i.e. top right) with a gears icon and a bunch of CSS swapping radio buttons in there. Currently, EDGE reading mode is doing this kind of thing. So I agree with Patrick on this. I think this is too much for a dot release, given our other new LVTF requirements which are more mature and achievable.

Contributor

DavidMacDonald commented Dec 19, 2016

My concern is that this really is a User agent issue. I dread the thought of telling large companies to use up prime real estate (i.e. top right) with a gears icon and a bunch of CSS swapping radio buttons in there. Currently, EDGE reading mode is doing this kind of thing. So I agree with Patrick on this. I think this is too much for a dot release, given our other new LVTF requirements which are more mature and achievable.

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Dec 19, 2016

Contributor

But no-one is saying that a website would have to provide customisation options.

If you use HTML you pass, if you use something else, you may need to provide options.

Contributor

alastc commented Dec 19, 2016

But no-one is saying that a website would have to provide customisation options.

If you use HTML you pass, if you use something else, you may need to provide options.

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Dec 20, 2016

Contributor

@allanj-uaag , @slhenry , and @WayneEDick your thoughts on whether this SC is a user agent issue and be should deferred to Silver? Please see David's and Patrick's comments.

The proposed text does say that "a mechanism is available...", which gives the impression of add-on widgets. Ideas to reword it?

Contributor

lauracarlson commented Dec 20, 2016

@allanj-uaag , @slhenry , and @WayneEDick your thoughts on whether this SC is a user agent issue and be should deferred to Silver? Please see David's and Patrick's comments.

The proposed text does say that "a mechanism is available...", which gives the impression of add-on widgets. Ideas to reword it?

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Dec 21, 2016

Contributor

So it seems people are having a similar reaction to me when when I joined the LVTF, thinking that it is requiring on-page widgets when in fact HTML passes by default.

There needs to be a way of saying that in the SC text, but somehow not make it technology specific!?

The closest thing in WCAG 2.0 is from 1.4.5 Images of text, which starts: “If the technologies being used can achieve…”

Perhaps something like “If the technologies being used do not provide element level access, a mechanism is available to achieve the following:"

Where "element level access" is a term for markup languages. Any other ideas?

Contributor

alastc commented Dec 21, 2016

So it seems people are having a similar reaction to me when when I joined the LVTF, thinking that it is requiring on-page widgets when in fact HTML passes by default.

There needs to be a way of saying that in the SC text, but somehow not make it technology specific!?

The closest thing in WCAG 2.0 is from 1.4.5 Images of text, which starts: “If the technologies being used can achieve…”

Perhaps something like “If the technologies being used do not provide element level access, a mechanism is available to achieve the following:"

Where "element level access" is a term for markup languages. Any other ideas?

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Dec 21, 2016

Contributor

Hi @DavidMacDonald and @patrickhlauke,

Would Alastair's suggested SC text work for you?

Thanks,
Laura

Contributor

lauracarlson commented Dec 21, 2016

Hi @DavidMacDonald and @patrickhlauke,

Would Alastair's suggested SC text work for you?

Thanks,
Laura

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Dec 21, 2016

Member

In practice, even with that particular text, it would mean requiring even HTML/CSS based sites that are to be displayed on the currently common mobile platforms/browsers to provide actual widgets/personalization options (since to my knowledge none of the browsers on iOS/Android/Windows Mobile provide this sort of element-level granular control, nor any form of user stylesheet options). So this seems very ambitious and onerous as a AA, even with that text.

Member

patrickhlauke commented Dec 21, 2016

In practice, even with that particular text, it would mean requiring even HTML/CSS based sites that are to be displayed on the currently common mobile platforms/browsers to provide actual widgets/personalization options (since to my knowledge none of the browsers on iOS/Android/Windows Mobile provide this sort of element-level granular control, nor any form of user stylesheet options). So this seems very ambitious and onerous as a AA, even with that text.

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Dec 21, 2016

Contributor

Thank you @patrickhlauke . I really appreciate your expertise on the mobile front. Can you think of any other possible way to word the SC that could work?

Contributor

lauracarlson commented Dec 21, 2016

Thank you @patrickhlauke . I really appreciate your expertise on the mobile front. Can you think of any other possible way to word the SC that could work?

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Dec 21, 2016

Member

I don't believe the problem is one of wording as such. It's just that no UA (on mobile/tablet) currently offers the necessary mechanism to satisfy the suggested requirement of the SC, meaning that in these scenarios authors effectively HAVE to provide a widget or some form of per-site personalization. Not sure how this tension could be resolved...if what the SC is proposing is indeed needed by particular user groups, one could argue that those user groups would not be using devices/UAs that don't provide this customisation option, but that's potentially a self-fulfilling prophecy/circular argument, unless I'm missing something obvious...

Member

patrickhlauke commented Dec 21, 2016

I don't believe the problem is one of wording as such. It's just that no UA (on mobile/tablet) currently offers the necessary mechanism to satisfy the suggested requirement of the SC, meaning that in these scenarios authors effectively HAVE to provide a widget or some form of per-site personalization. Not sure how this tension could be resolved...if what the SC is proposing is indeed needed by particular user groups, one could argue that those user groups would not be using devices/UAs that don't provide this customisation option, but that's potentially a self-fulfilling prophecy/circular argument, unless I'm missing something obvious...

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Dec 22, 2016

Contributor

Thanks, @patrickhlauke .

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

Contributor

lauracarlson commented Dec 22, 2016

Thanks, @patrickhlauke .

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

@goetsu

This comment has been minimized.

Show comment
Hide comment
@goetsu

goetsu Dec 26, 2016

Is it an invitation for authors to implement feature to let user choose spacing he want ? in that case better to be AAA I think because can be costly to implement

goetsu commented Dec 26, 2016

Is it an invitation for authors to implement feature to let user choose spacing he want ? in that case better to be AAA I think because can be costly to implement

@bruce-usab

This comment has been minimized.

Show comment
Hide comment
@bruce-usab

bruce-usab Jan 3, 2017

Just now signing up for GitHub...

I am okay with this SC, but think it needs to be at same level as 1.4.8 (currently AAA) because (as compared to 1.4.8):

  • It does less for people low vision (I think)
  • It impacts the visual design more
  • It is more work for content authors

I would also recommend a note similar to 4.1.2:

This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.

bruce-usab commented Jan 3, 2017

Just now signing up for GitHub...

I am okay with this SC, but think it needs to be at same level as 1.4.8 (currently AAA) because (as compared to 1.4.8):

  • It does less for people low vision (I think)
  • It impacts the visual design more
  • It is more work for content authors

I would also recommend a note similar to 4.1.2:

This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Jan 5, 2017

Contributor

On the January 5, 2016 LVTF call we discussed having an exception for UAs that do not provide a way to adjust spacing. If the user-agent does not have a way (such as mobile does not currently allow user style sheets), authors would be exempt. This SC would not be applicable in those cases.

However, 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 at AA where it is accessibility supported via user stylesheets would be a big benefit.

@slhenry also mentioned that having a failure technique for authors using element-level CSS marked important for spacing would be helpful for people with low vision because per @WayneEDick users can't overwrite that to what they need. Both Wayne and Shawn are user style sheet users.

First attempt at rewording the SC:

For the visual presentation of blocks of text:

  • character spacing can be selected by the user
  • word spacing can be selected by the user
  • line spacing can be selected by the user
  • paragraph spacing can be selected by the user

with following the exception:

  • If the user agent prohibits adjustments the content is exempt.

@DavidMacDonald , @patrickhlauke, @bruce-usab , @alastc thoughts?

Contributor

lauracarlson commented Jan 5, 2017

On the January 5, 2016 LVTF call we discussed having an exception for UAs that do not provide a way to adjust spacing. If the user-agent does not have a way (such as mobile does not currently allow user style sheets), authors would be exempt. This SC would not be applicable in those cases.

However, 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 at AA where it is accessibility supported via user stylesheets would be a big benefit.

@slhenry also mentioned that having a failure technique for authors using element-level CSS marked important for spacing would be helpful for people with low vision because per @WayneEDick users can't overwrite that to what they need. Both Wayne and Shawn are user style sheet users.

First attempt at rewording the SC:

For the visual presentation of blocks of text:

  • character spacing can be selected by the user
  • word spacing can be selected by the user
  • line spacing can be selected by the user
  • paragraph spacing can be selected by the user

with following the exception:

  • If the user agent prohibits adjustments the content is exempt.

@DavidMacDonald , @patrickhlauke, @bruce-usab , @alastc thoughts?

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Jan 5, 2017

Contributor

@goetsu No this SC is not about spacing widgets. It is more about letting People with Low Vision who use desktop browsers apply their own stylesheets without authors introducing barriers.

Contributor

lauracarlson commented Jan 5, 2017

@goetsu No this SC is not about spacing widgets. It is more about letting People with Low Vision who use desktop browsers apply their own stylesheets without authors introducing barriers.

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jan 6, 2017

Contributor

The SC does not just call for the ability for users to control spacing, but specifies that a "mechanism" is available to provide that spacing. From that perspective I feel that it does imply that authors are required to customize a mechanism.
There are 8 existing SC that refer to providing "mechanisms", six of which are AAA:
audio control (A)
visual presentation (AAA)
bypass blocks (A)
link purpose (AAA)
unusual words (AAA)
abbreviations (AAA)
pronunciation (AAA)
change on request (AAA)

These break down into 3 broad categories:

  1. situations where IF the author create certain potentially inaccessible content, they provide a means of overcoming it (automatically starting audio; using words in an unusual way; using abbreviations; repeating blocks of content on multiple pages )
  2. situations where IF authors don't follow best practices, they provide a means of overcoming the potential issue (link purpose not clear from link text alone; change of context are initiated without user request; meaning of word is ambiguous without knowing pronunciation)
  3. the mechanism offers manipulation of information, regardless of author decisions on content (Visual presentation)

This candidate SC aligns very closely with the third case. In fact the 4th requirement for Visual presentation is a near-cousin ("Techniques to ensure 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").

Given that Visual Presentation is AAA, it is tough to rationalize giving this candidate SC a AA designation. As well, it's tough to say this should be a lower level than AAA, because unlike other A and AA that call for mechanisms due to author decisions, this one requires a mechanism regardless of what is being authored.

If the SC wording was altered so that the requirement was not to provide a mechanism, I wonder if this might be easier to consider as a AA. For instance:
"For all text presented in the content, each of the following is true:
word spacing can be adjusted by the user
line spacing can be adjusted by the user
paragraph spacing can be adjusted by the user "

There may be general techniques that could be written to ensure authors do not interfere with user agents (such as G204) or perhaps some CSS techniques which encourage rather than limit malleable spacing. Other have pointed out the technical limitations for some user agents; if someone wanted to support accessibility on such a user agent, they would need to provide a mechanism.

Contributor

mbgower commented Jan 6, 2017

The SC does not just call for the ability for users to control spacing, but specifies that a "mechanism" is available to provide that spacing. From that perspective I feel that it does imply that authors are required to customize a mechanism.
There are 8 existing SC that refer to providing "mechanisms", six of which are AAA:
audio control (A)
visual presentation (AAA)
bypass blocks (A)
link purpose (AAA)
unusual words (AAA)
abbreviations (AAA)
pronunciation (AAA)
change on request (AAA)

These break down into 3 broad categories:

  1. situations where IF the author create certain potentially inaccessible content, they provide a means of overcoming it (automatically starting audio; using words in an unusual way; using abbreviations; repeating blocks of content on multiple pages )
  2. situations where IF authors don't follow best practices, they provide a means of overcoming the potential issue (link purpose not clear from link text alone; change of context are initiated without user request; meaning of word is ambiguous without knowing pronunciation)
  3. the mechanism offers manipulation of information, regardless of author decisions on content (Visual presentation)

This candidate SC aligns very closely with the third case. In fact the 4th requirement for Visual presentation is a near-cousin ("Techniques to ensure 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").

Given that Visual Presentation is AAA, it is tough to rationalize giving this candidate SC a AA designation. As well, it's tough to say this should be a lower level than AAA, because unlike other A and AA that call for mechanisms due to author decisions, this one requires a mechanism regardless of what is being authored.

If the SC wording was altered so that the requirement was not to provide a mechanism, I wonder if this might be easier to consider as a AA. For instance:
"For all text presented in the content, each of the following is true:
word spacing can be adjusted by the user
line spacing can be adjusted by the user
paragraph spacing can be adjusted by the user "

There may be general techniques that could be written to ensure authors do not interfere with user agents (such as G204) or perhaps some CSS techniques which encourage rather than limit malleable spacing. Other have pointed out the technical limitations for some user agents; if someone wanted to support accessibility on such a user agent, they would need to provide a mechanism.

@goetsu

This comment has been minimized.

Show comment
Hide comment
@goetsu

goetsu Jan 6, 2017

@lauracarlson I understand it better now thanks for your comment.

I agree we must have an exception if the UA doesn't have a feature to let user change spacing adjustments but are you aware of any UA that allow to change it ?

From what I know it not the case for at least Firefox, Safari and Internet Explorer so basically this SC will be always non applicable for now.

Maybe we can consider that Internet Explorer has this feature because it let user specify a user style sheet without any plugin or extension. But, in that case the failure you mention doesn't work because user stylesheet value marked as !important have more weight than author value marked as !important. So the issue isn't about using !important or not it's more about the face that when user use is own stylesheet content must not become unreable if his stylesheet increase spacing

goetsu commented Jan 6, 2017

@lauracarlson I understand it better now thanks for your comment.

I agree we must have an exception if the UA doesn't have a feature to let user change spacing adjustments but are you aware of any UA that allow to change it ?

From what I know it not the case for at least Firefox, Safari and Internet Explorer so basically this SC will be always non applicable for now.

Maybe we can consider that Internet Explorer has this feature because it let user specify a user style sheet without any plugin or extension. But, in that case the failure you mention doesn't work because user stylesheet value marked as !important have more weight than author value marked as !important. So the issue isn't about using !important or not it's more about the face that when user use is own stylesheet content must not become unreable if his stylesheet increase spacing

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Jan 6, 2017

Member

Indeed, if user styles are the intended "mechanism" that comes out of the box (rather than requiring an explicit widget etc), it seems that user stylesheets are currently are not supported by Edge at all, and supported in Firefox and Chrome only through the use of third-party plugins. Internet Explorer and Safari still provide options in their settings for them (in IE: Internet Options > General > Accessibility; in Safari: Safari menu > Preferences > Advanced).

And yes, @goetsu is right that !important in a user style should take precedence over author styles, even when those have !important too.

So the issue isn't about using !important or not it's more about the face that when user use is own stylesheet content must not become unreable if his stylesheet increase spacing

The one danger I can see here is that user styles are an unknown quantity for both authors and auditors. It will be difficult to explicitly author against and test all possible values/ways in which user styles try to affect a page. At the very least, a sample "ideal" user stylesheet should be provided for consistent testing, but that still won't guarantee that real-world user stylesheets will do exactly the same, and may still result in situations where a site does not display correctly anymore due to some unforeseen user CSS.

Member

patrickhlauke commented Jan 6, 2017

Indeed, if user styles are the intended "mechanism" that comes out of the box (rather than requiring an explicit widget etc), it seems that user stylesheets are currently are not supported by Edge at all, and supported in Firefox and Chrome only through the use of third-party plugins. Internet Explorer and Safari still provide options in their settings for them (in IE: Internet Options > General > Accessibility; in Safari: Safari menu > Preferences > Advanced).

And yes, @goetsu is right that !important in a user style should take precedence over author styles, even when those have !important too.

So the issue isn't about using !important or not it's more about the face that when user use is own stylesheet content must not become unreable if his stylesheet increase spacing

The one danger I can see here is that user styles are an unknown quantity for both authors and auditors. It will be difficult to explicitly author against and test all possible values/ways in which user styles try to affect a page. At the very least, a sample "ideal" user stylesheet should be provided for consistent testing, but that still won't guarantee that real-world user stylesheets will do exactly the same, and may still result in situations where a site does not display correctly anymore due to some unforeseen user CSS.

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Jan 6, 2017

Contributor

Thanks @mbgower !

Mike, I like your proposed SC text better than my first attempt at it. Much simpler. And the word "adjusted" makes more sense than the word "selected".

Do you think we still need the exceptions? I had the following the exceptions:

  • If spacing of content is essential to that contents use, that part of the content is exempt.
  • If the user agent prohibits spacing adjustments the content is exempt.

A general technique to ensure authors do not interfere with user agents (such as G204) and CSS techniques which encourage rather than limit malleable spacing are great ideas.

Contributor

lauracarlson commented Jan 6, 2017

Thanks @mbgower !

Mike, I like your proposed SC text better than my first attempt at it. Much simpler. And the word "adjusted" makes more sense than the word "selected".

Do you think we still need the exceptions? I had the following the exceptions:

  • If spacing of content is essential to that contents use, that part of the content is exempt.
  • If the user agent prohibits spacing adjustments the content is exempt.

A general technique to ensure authors do not interfere with user agents (such as G204) and CSS techniques which encourage rather than limit malleable spacing are great ideas.

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Jan 6, 2017

Contributor

Hi @goetsu ,

You are welcome. Thank you for your comment, Aurélien. You asked:

I agree we must have an exception if the UA doesn't have a feature to let user change spacing adjustments but are you aware of any UA that allow to change it ?

VIP PDF Reader was mentioned in the January 5, 2017 LVTF meeting.

But I haven't been able to get it to work. Can anyone?

Contributor

lauracarlson commented Jan 6, 2017

Hi @goetsu ,

You are welcome. Thank you for your comment, Aurélien. You asked:

I agree we must have an exception if the UA doesn't have a feature to let user change spacing adjustments but are you aware of any UA that allow to change it ?

VIP PDF Reader was mentioned in the January 5, 2017 LVTF meeting.

But I haven't been able to get it to work. Can anyone?

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Jan 6, 2017

Contributor

Hi @patrickhlauke ,

Thank you very much for your comment, Patrick. You wrote:

The one danger I can see here is that user styles are an unknown quantity for both authors and auditors. It will be difficult to explicitly author against and test all possible values/ways in which user styles try to affect a page. At the very least, a sample "ideal" user stylesheet should be provided for consistent testing, but that still won't guarantee that real-world user stylesheets will do exactly the same, and may still result in situations where a site does not display correctly anymore due to some unforeseen user CSS.

Both @slhenry and @WayneEDick are user style sheet users. Shawn and Wayne would it be possible for you two to collaborate to create such a sample "ideal" user stylesheet?

In the the January 5, 2017 LVTF meeting it was mentioned that !important can't be overwritten by users. Shawn and Wayne, do either of you have an example of where this has occurred for you?

Contributor

lauracarlson commented Jan 6, 2017

Hi @patrickhlauke ,

Thank you very much for your comment, Patrick. You wrote:

The one danger I can see here is that user styles are an unknown quantity for both authors and auditors. It will be difficult to explicitly author against and test all possible values/ways in which user styles try to affect a page. At the very least, a sample "ideal" user stylesheet should be provided for consistent testing, but that still won't guarantee that real-world user stylesheets will do exactly the same, and may still result in situations where a site does not display correctly anymore due to some unforeseen user CSS.

Both @slhenry and @WayneEDick are user style sheet users. Shawn and Wayne would it be possible for you two to collaborate to create such a sample "ideal" user stylesheet?

In the the January 5, 2017 LVTF meeting it was mentioned that !important can't be overwritten by users. Shawn and Wayne, do either of you have an example of where this has occurred for you?

@WayneEDick

This comment has been minimized.

Show comment
Hide comment
@WayneEDick

WayneEDick Jan 8, 2017

Contributor

In fact a mechanism does exist for at least two user agents to enable user style sheets. So mechanisms exist that are available to users with low vision to apply user style sheets. So, If one uses a laptop or a desktop one can change line, letter and word spacing.
If no mechanism exists for a technology then authors are off the hook. But I don't see why authors of HTML should not code in a way to prevent user style. One that I have run into for example is the use of !important is "style" parameters.

Wayne.

Wayne

Contributor

WayneEDick commented Jan 8, 2017

In fact a mechanism does exist for at least two user agents to enable user style sheets. So mechanisms exist that are available to users with low vision to apply user style sheets. So, If one uses a laptop or a desktop one can change line, letter and word spacing.
If no mechanism exists for a technology then authors are off the hook. But I don't see why authors of HTML should not code in a way to prevent user style. One that I have run into for example is the use of !important is "style" parameters.

Wayne.

Wayne

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Jan 8, 2017

Member

Random thought: then why not generalise the SC so that all sorts of presentational attributes (beyond just spacing) can be changed using user styles or similar? And the failure examples could then include things like !important and style attributes?

Member

patrickhlauke commented Jan 8, 2017

Random thought: then why not generalise the SC so that all sorts of presentational attributes (beyond just spacing) can be changed using user styles or similar? And the failure examples could then include things like !important and style attributes?

@jnurthen

This comment has been minimized.

Show comment
Hide comment
@jnurthen

jnurthen Jan 8, 2017

jnurthen commented Jan 8, 2017

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Jan 8, 2017

Member

Why would !important and inline style attributes fail? An element defined
with !important in the user style sheet will override both of these in the
source document as far as I'm aware.

Just tested this, and yes you're right: providing that a user stylesheet is written appropriately, !important in the author's styles and style attributes do NOT override the user styles. As such, I'd be interested in seeing some hard examples of where authors are breaking user styles... (and where it's not simply the user styles that need to be written more specifically with their selectors - e.g. not just setting style rules purely on body or html, but perhaps using catch-all star selectors * { ... } )

Member

patrickhlauke commented Jan 8, 2017

Why would !important and inline style attributes fail? An element defined
with !important in the user style sheet will override both of these in the
source document as far as I'm aware.

Just tested this, and yes you're right: providing that a user stylesheet is written appropriately, !important in the author's styles and style attributes do NOT override the user styles. As such, I'd be interested in seeing some hard examples of where authors are breaking user styles... (and where it's not simply the user styles that need to be written more specifically with their selectors - e.g. not just setting style rules purely on body or html, but perhaps using catch-all star selectors * { ... } )

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Jan 8, 2017

Contributor

it's not simply the user styles that need to be written more specifically with their selectors

I'm not sure I understand, did you mean the selectors would have to be specific for the site? Or that using the star selector is the better approach? (Which seems the opposite of more specific?)

Contributor

alastc commented Jan 8, 2017

it's not simply the user styles that need to be written more specifically with their selectors

I'm not sure I understand, did you mean the selectors would have to be specific for the site? Or that using the star selector is the better approach? (Which seems the opposite of more specific?)

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Jan 8, 2017

Member

specifically as in "with the specific intent of working in a variety of situations". admittedly a poor choice of words, so let's pretend i wrote "more generally" instead.

Member

patrickhlauke commented Jan 8, 2017

specifically as in "with the specific intent of working in a variety of situations". admittedly a poor choice of words, so let's pretend i wrote "more generally" instead.

@awkawk awkawk changed the title from Spacing - Ready for Review to Spacing Jan 9, 2017

@WayneEDick

This comment has been minimized.

Show comment
Hide comment
@WayneEDick

WayneEDick Jan 9, 2017

Contributor
Contributor

WayneEDick commented Jan 9, 2017

@WayneEDick

This comment has been minimized.

Show comment
Hide comment
@WayneEDick

WayneEDick Jan 9, 2017

Contributor

The term a mechanism does not imply a user agent restriction. For example, the accessibility API for a system is a mechanism, without which much of WCAG and ARIA are useless. User style sheets and user agent extensions are such mechanisms. Fortunately two major user agents have extensions that support user style sheets. That means that a mechanism exists to change style, presentations like, spacing and font-family.

If no user agent for a given file technology exists that provides this mechanism, then the author is not responsible for supporting the mechanism using that file technology. However, if a user agent exists with that support then the author must do nothing to interfer with that support.

I have seen very bad pages that include !important in "style" parameters of html elements. That is unacceptable. ​

To say that user style sheets are not an existing mechanism is just technology bias. WCAG is not supposed to be technology bias for assistive technology either.

I completely reject the premise that "a mechanism exists" automatically moves a success criterion to silver. It is a false premise.

Contributor

WayneEDick commented Jan 9, 2017

The term a mechanism does not imply a user agent restriction. For example, the accessibility API for a system is a mechanism, without which much of WCAG and ARIA are useless. User style sheets and user agent extensions are such mechanisms. Fortunately two major user agents have extensions that support user style sheets. That means that a mechanism exists to change style, presentations like, spacing and font-family.

If no user agent for a given file technology exists that provides this mechanism, then the author is not responsible for supporting the mechanism using that file technology. However, if a user agent exists with that support then the author must do nothing to interfer with that support.

I have seen very bad pages that include !important in "style" parameters of html elements. That is unacceptable. ​

To say that user style sheets are not an existing mechanism is just technology bias. WCAG is not supposed to be technology bias for assistive technology either.

I completely reject the premise that "a mechanism exists" automatically moves a success criterion to silver. It is a false premise.

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Jan 9, 2017

Contributor

Laura asked about important not being able to be overwritten by the user. In my experience when user agents allow for user styles those can override. However, many browser's don't offer this anymore and thus we must use tools, plug-ins and bookmarklets like the Stylish extension. When using these extensions the scripts are inserted into the page at the document level and thus "important" may not be able to be overwritten in my experience.

Contributor

mraccess77 commented Jan 9, 2017

Laura asked about important not being able to be overwritten by the user. In my experience when user agents allow for user styles those can override. However, many browser's don't offer this anymore and thus we must use tools, plug-ins and bookmarklets like the Stylish extension. When using these extensions the scripts are inserted into the page at the document level and thus "important" may not be able to be overwritten in my experience.

@WayneEDick

This comment has been minimized.

Show comment
Hide comment
@WayneEDick

WayneEDick Jan 9, 2017

Contributor

The instances of inline !important are rare, but I have found them very hard to override. The main problem is that user style sheets have the lowest priority of all, and inline style has the highest. However, the following extremely general CSS will ferret out most 'stinker' pages.

  • {
    line-height: 1.36 !important;
    letter-spacing: 0.03em !important;
    word-spacing: 0.07em !important;
    }

The only real problem caused by changing spacing, and I find it about every three months is that spacing acts a little like enlargement in that it usually takes more space. But most pages do this pretty well.

I really think that the exception language of Laura frees authors of technologies where no user agent exists with support of spacing control.

Her intent is clear. If a file format like HTML has a mechanism like user style sheets on some user agents then all an author has to do to test if a page passes is to include the CSS above as the very last style statement in their code. Last in the CSS line with !important beats everything, even specificity.

An accessibility tester can use Stylish with the same code. If any elements or classes fail to space they can be noted as failures.

This is a general issue with low vision. We need access to restyle. We do not want to force authors on technologies like Silverlight or PDF or rigid mobile to create local widgets. We just need authors to code accessibly for user agents that do support restyling. The former expectation is well beyond the scope of 2.1, but the latter splits the case into to technologies that can and technologies that cannot leaving the author off the hook.

Contributor

WayneEDick commented Jan 9, 2017

The instances of inline !important are rare, but I have found them very hard to override. The main problem is that user style sheets have the lowest priority of all, and inline style has the highest. However, the following extremely general CSS will ferret out most 'stinker' pages.

  • {
    line-height: 1.36 !important;
    letter-spacing: 0.03em !important;
    word-spacing: 0.07em !important;
    }

The only real problem caused by changing spacing, and I find it about every three months is that spacing acts a little like enlargement in that it usually takes more space. But most pages do this pretty well.

I really think that the exception language of Laura frees authors of technologies where no user agent exists with support of spacing control.

Her intent is clear. If a file format like HTML has a mechanism like user style sheets on some user agents then all an author has to do to test if a page passes is to include the CSS above as the very last style statement in their code. Last in the CSS line with !important beats everything, even specificity.

An accessibility tester can use Stylish with the same code. If any elements or classes fail to space they can be noted as failures.

This is a general issue with low vision. We need access to restyle. We do not want to force authors on technologies like Silverlight or PDF or rigid mobile to create local widgets. We just need authors to code accessibly for user agents that do support restyling. The former expectation is well beyond the scope of 2.1, but the latter splits the case into to technologies that can and technologies that cannot leaving the author off the hook.

@WayneEDick

This comment has been minimized.

Show comment
Hide comment
@WayneEDick

WayneEDick Jan 9, 2017

Contributor

We left general element level style accommodation off the list, but maybe we should have included it.
What people with low vision really need is non-interference from authors when it comes to altering the visual presentation of content wherever there are user agents that support changes in visual presentation. This non-interference should apply all the way to the element level.

Contributor

WayneEDick commented Jan 9, 2017

We left general element level style accommodation off the list, but maybe we should have included it.
What people with low vision really need is non-interference from authors when it comes to altering the visual presentation of content wherever there are user agents that support changes in visual presentation. This non-interference should apply all the way to the element level.

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Jan 9, 2017

Contributor
Contributor

mraccess77 commented Jan 9, 2017

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Jan 9, 2017

Member

The main problem is that user style sheets have the lowest priority of all, and inline style has the highest.

this is not a problem of priority, but rather of CSS specificity and cascade. If you've got very generic style definitions in your user styles, they At the same level of CSS specificity, user styles (if implemented in the true sense, i.e. natively in browser rather than through a third-party extension that simply inserts them into the document level) trump inline styles, document styles, etc.

as a simplified example if you just define a very high level body { color: black; background: white; } or even body { color: black !important; background: white !important; } in the user stylesheet, and CSS with a higher specificity in its selector will override this...and this is simply the way CSS works. for instance, div#foo { ... } will have a higher specificity and override the lower specificity body { ... } selector.

Member

patrickhlauke commented Jan 9, 2017

The main problem is that user style sheets have the lowest priority of all, and inline style has the highest.

this is not a problem of priority, but rather of CSS specificity and cascade. If you've got very generic style definitions in your user styles, they At the same level of CSS specificity, user styles (if implemented in the true sense, i.e. natively in browser rather than through a third-party extension that simply inserts them into the document level) trump inline styles, document styles, etc.

as a simplified example if you just define a very high level body { color: black; background: white; } or even body { color: black !important; background: white !important; } in the user stylesheet, and CSS with a higher specificity in its selector will override this...and this is simply the way CSS works. for instance, div#foo { ... } will have a higher specificity and override the lower specificity body { ... } selector.

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Jul 11, 2017

Contributor

Hi @mbgower

Hi, I had to drop from the call today, and missed last Thursday's so can anyone provide a quick summary of why paragraph is coming back in? I'm inclined to agree with Steve's perspective that there may be ramifications to including paragraph in here.

@lseeman objected to the SC without it. Check the survey.

BTW, shouldn't it be "...any of the following:..." or "any or all of the following", not "...adapting all of the following:..."? Otherwise, I'd think you'd have a situation where if you only adapted some of them it wouldn't fail this.

The original intent was it to be all of the bullets. But we could change it.

Contributor

lauracarlson commented Jul 11, 2017

Hi @mbgower

Hi, I had to drop from the call today, and missed last Thursday's so can anyone provide a quick summary of why paragraph is coming back in? I'm inclined to agree with Steve's perspective that there may be ramifications to including paragraph in here.

@lseeman objected to the SC without it. Check the survey.

BTW, shouldn't it be "...any of the following:..." or "any or all of the following", not "...adapting all of the following:..."? Otherwise, I'd think you'd have a situation where if you only adapted some of them it wouldn't fail this.

The original intent was it to be all of the bullets. But we could change it.

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Jul 11, 2017

Contributor

Hi @steverep ,

You wrote:

Again, "the technology's default font size" is not the desired requirement at all. This means that since most browser's will default to a font size of 16px or Word defaults to 11pt, then we want 1.5 times that which is not the case at all and is a very confusing requirement. I understand you're trying to address differences in font height, but that's a property of the font itself, not the technology, and doesn't change the desired numerical specification of any spacing property.

Okay, we can take that out.

As far as restricting the spacing to blocks of text, that results in the same problem as trying to adapt paragraph spacing. There's no golden set of simple CSS rules that will always result in the desired text presentation, at least not without making big assumptions on tags used and other layout aspects.

@alastc do you agree? You introduced the blocks of text language on the LVTF list.

We need to drop bullet 2 until we can solve this problem, and I would much rather tweak the actual spacing numbers rather than to types of elements for ease of testability. Let's get it in the editor's draft and alter the note to say we're working on the final spacing numbers.

Then I am afraid, we will not get this SC into 2.1 because of @lseeman 's objection.

Lisa can you possibility live without the paragraph bullet?

Thanks,
Laura

Contributor

lauracarlson commented Jul 11, 2017

Hi @steverep ,

You wrote:

Again, "the technology's default font size" is not the desired requirement at all. This means that since most browser's will default to a font size of 16px or Word defaults to 11pt, then we want 1.5 times that which is not the case at all and is a very confusing requirement. I understand you're trying to address differences in font height, but that's a property of the font itself, not the technology, and doesn't change the desired numerical specification of any spacing property.

Okay, we can take that out.

As far as restricting the spacing to blocks of text, that results in the same problem as trying to adapt paragraph spacing. There's no golden set of simple CSS rules that will always result in the desired text presentation, at least not without making big assumptions on tags used and other layout aspects.

@alastc do you agree? You introduced the blocks of text language on the LVTF list.

We need to drop bullet 2 until we can solve this problem, and I would much rather tweak the actual spacing numbers rather than to types of elements for ease of testability. Let's get it in the editor's draft and alter the note to say we're working on the final spacing numbers.

Then I am afraid, we will not get this SC into 2.1 because of @lseeman 's objection.

Lisa can you possibility live without the paragraph bullet?

Thanks,
Laura

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Jul 11, 2017

Contributor

I didn't get a chance to comment on the call about it on the call, but I think the addition of 'plus default' is causing more problems than it is solving.

If you think about the mechanism, it is an over-ride, you would set the values to what you want, and these values act as a largest-size to test with.

Therefore the normal / default / technology default value doesn't make any difference, and adding it simply confused things.

Regarding blocks of text, @steverep is right that:

There's no golden set of simple CSS rules that will always result in the desired text presentation

However, it is a case of either:

  1. Applying to all text and using values that won't definitely break layouts (some will, but allowing for a bit of buffer would probably be acceptable).
  2. Applying to blocks of text only, with whatever value that makes sense from a user point of view.

The mechanism on the user-side would have to restrict the changes to block elements such as p, li, h1, h2 etc. in HTML. In PDF (with reflow) or ePub it wouldn't be a big issue as all text is essentially in block elements.

It does make it a bit riskier to apply, a user-side script has a greater chance of missing things if it is restricted to particular tags. However, adding more than 10-15% to the width of all text will break things and there isn't much an author can reliably do to prevent that.

So for the paragraph bullet (especially considering it is in the current 1.4.8 Visual Presentation) I don't think that's a problem because it is one specific element, and one that happily expands vertically in virtually every situation.

I think we should get rid of the 'default' aspects, it is counter to the point of the SC, but I don't object to getting it out and working on the values more.

Contributor

alastc commented Jul 11, 2017

I didn't get a chance to comment on the call about it on the call, but I think the addition of 'plus default' is causing more problems than it is solving.

If you think about the mechanism, it is an over-ride, you would set the values to what you want, and these values act as a largest-size to test with.

Therefore the normal / default / technology default value doesn't make any difference, and adding it simply confused things.

Regarding blocks of text, @steverep is right that:

There's no golden set of simple CSS rules that will always result in the desired text presentation

However, it is a case of either:

  1. Applying to all text and using values that won't definitely break layouts (some will, but allowing for a bit of buffer would probably be acceptable).
  2. Applying to blocks of text only, with whatever value that makes sense from a user point of view.

The mechanism on the user-side would have to restrict the changes to block elements such as p, li, h1, h2 etc. in HTML. In PDF (with reflow) or ePub it wouldn't be a big issue as all text is essentially in block elements.

It does make it a bit riskier to apply, a user-side script has a greater chance of missing things if it is restricted to particular tags. However, adding more than 10-15% to the width of all text will break things and there isn't much an author can reliably do to prevent that.

So for the paragraph bullet (especially considering it is in the current 1.4.8 Visual Presentation) I don't think that's a problem because it is one specific element, and one that happily expands vertically in virtually every situation.

I think we should get rid of the 'default' aspects, it is counter to the point of the SC, but I don't object to getting it out and working on the values more.

@steverep

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep Jul 11, 2017

Member

Therefore the normal / default / technology default value doesn't make any difference, and adding it simply confused things.

But normal in the CSS property value sense is not the same as what is meant by "default" here. The problem is to be technology agnostic, we need to realize that in CSS the actual spacing between 2 words, i.e. from the last letter of one word to the first letter of the next word, is really:

0.25em + letter-spacing + word-spacing

So despite the fact that the criterion says "word spacing", we actually mean "CSS word-spacing", resulting in actual spacing of 0.25 + 0.12 + 0.16 = 0.53em.

That said, I'm starting to agree that it's confusing to have the "plus..." language. I think things can be better explained in a technology-specific note.

Member

steverep commented Jul 11, 2017

Therefore the normal / default / technology default value doesn't make any difference, and adding it simply confused things.

But normal in the CSS property value sense is not the same as what is meant by "default" here. The problem is to be technology agnostic, we need to realize that in CSS the actual spacing between 2 words, i.e. from the last letter of one word to the first letter of the next word, is really:

0.25em + letter-spacing + word-spacing

So despite the fact that the criterion says "word spacing", we actually mean "CSS word-spacing", resulting in actual spacing of 0.25 + 0.12 + 0.16 = 0.53em.

That said, I'm starting to agree that it's confusing to have the "plus..." language. I think things can be better explained in a technology-specific note.

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Jul 11, 2017

Contributor

If you adjust spacing (word or letter) in CSS it is adding (or subtracting with negative numbers) from the default. It is the same for VIP reader for PDFs, and I assume it would be for ePub (based on XHTML & CSS).

Is there anywhere people can adjust these values on the user-end that do not start with 0 as the default?

Contributor

alastc commented Jul 11, 2017

If you adjust spacing (word or letter) in CSS it is adding (or subtracting with negative numbers) from the default. It is the same for VIP reader for PDFs, and I assume it would be for ePub (based on XHTML & CSS).

Is there anywhere people can adjust these values on the user-end that do not start with 0 as the default?

@WayneEDick

This comment has been minimized.

Show comment
Hide comment
@WayneEDick

WayneEDick Jul 11, 2017

Contributor
Contributor

WayneEDick commented Jul 11, 2017

@WayneEDick

This comment has been minimized.

Show comment
Hide comment
@WayneEDick

WayneEDick Jul 12, 2017

Contributor
Contributor

WayneEDick commented Jul 12, 2017

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Jul 12, 2017

Contributor

Hello everyone,

FYI:
I just posted the following message regarding Units: spaces, paragraphs, and ems to the AG List:

Hello John, Greg, Detlev, Jason, and everyone,

Based on Wayne's research and analysis, I previously suggest the following for the Adapting text SC.

  1. line spacing (leading) to at least 1.5 (space-and-a-half)
  2. spacing between paragraphs to at least 2 (two spaces) larger than the line spacing
  3. letter spacing (tracking) to at least 0.12 em
  4. word spacing to at least 0.16 em

On the call yesterday [1], some folks brought up that they felt the use of "spaces" to measure leading for the Adapting Text SC is untestable. At one point line-height was suggested.

Detlev, you were absolutely correct when you said, "if memory serves line-height needs no unit". In CSS line-height is unitless. Eric Meyer explained that in "Unitless line-heights". [2] It inherits from the font size. This was discussed on in the Adapting text GitHub Issue last March [3].

Moreover, WCAG 2.0 1.4.8 Visual Presentation [4] uses the "spaces" and "paragraphs" for units. It states:

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

Is that currently untestable? If not, why not re-purpose that terminology?

As for using ems as a unit perhaps we need a definition because that is a new concept for WCAG. How about something like:

em: A length unit relative to the font-size that is used. e.g., letter spacing of 0.12 em means 0.12 spacing in addition to the default space between letters of the font size in use.

Ideas for improvement? Other thoughts?

Thanks everyone.

Kindest regards,
Laura

[1] https://www.w3.org/2017/07/11-ag-minutes.html#item02
[2] http://meyerweb.com/eric/thoughts/2006/02/08/unitless-line-heights/
[3] #78 (comment)
[4] http://www.w3.org/TR/WCAG20#visual-audio-contrast-visual-presentation

--
Laura L. Carlson

Contributor

lauracarlson commented Jul 12, 2017

Hello everyone,

FYI:
I just posted the following message regarding Units: spaces, paragraphs, and ems to the AG List:

Hello John, Greg, Detlev, Jason, and everyone,

Based on Wayne's research and analysis, I previously suggest the following for the Adapting text SC.

  1. line spacing (leading) to at least 1.5 (space-and-a-half)
  2. spacing between paragraphs to at least 2 (two spaces) larger than the line spacing
  3. letter spacing (tracking) to at least 0.12 em
  4. word spacing to at least 0.16 em

On the call yesterday [1], some folks brought up that they felt the use of "spaces" to measure leading for the Adapting Text SC is untestable. At one point line-height was suggested.

Detlev, you were absolutely correct when you said, "if memory serves line-height needs no unit". In CSS line-height is unitless. Eric Meyer explained that in "Unitless line-heights". [2] It inherits from the font size. This was discussed on in the Adapting text GitHub Issue last March [3].

Moreover, WCAG 2.0 1.4.8 Visual Presentation [4] uses the "spaces" and "paragraphs" for units. It states:

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

Is that currently untestable? If not, why not re-purpose that terminology?

As for using ems as a unit perhaps we need a definition because that is a new concept for WCAG. How about something like:

em: A length unit relative to the font-size that is used. e.g., letter spacing of 0.12 em means 0.12 spacing in addition to the default space between letters of the font size in use.

Ideas for improvement? Other thoughts?

Thanks everyone.

Kindest regards,
Laura

[1] https://www.w3.org/2017/07/11-ag-minutes.html#item02
[2] http://meyerweb.com/eric/thoughts/2006/02/08/unitless-line-heights/
[3] #78 (comment)
[4] http://www.w3.org/TR/WCAG20#visual-audio-contrast-visual-presentation

--
Laura L. Carlson

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Jul 14, 2017

Contributor

Hello everyone,

FYI:
I just posted the following message Please Review: Final draft wording to allow Adapting Text into the Editors Draft to the AG List:

Hi John, Greg, Lisa, and Everyone,

After reading the "Adapting Text Units: Spaces, paragraphs, and ems" thread [1] and Stephen's latest rationale [2], can anyone not live with the following 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.

Can anyone not live with that?

Thank you all very much.

Kindest Regards,
Laura

[1] https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JulSep/thread.html#msg61
[2] https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JulSep/0111.html

Contributor

lauracarlson commented Jul 14, 2017

Hello everyone,

FYI:
I just posted the following message Please Review: Final draft wording to allow Adapting Text into the Editors Draft to the AG List:

Hi John, Greg, Lisa, and Everyone,

After reading the "Adapting Text Units: Spaces, paragraphs, and ems" thread [1] and Stephen's latest rationale [2], can anyone not live with the following 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.

Can anyone not live with that?

Thank you all very much.

Kindest Regards,
Laura

[1] https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JulSep/thread.html#msg61
[2] https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JulSep/0111.html

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Jul 14, 2017

Contributor

I can live with it.

Contributor

DavidMacDonald commented Jul 14, 2017

I can live with it.

@johnfoliot

This comment has been minimized.

Show comment
Hide comment
@johnfoliot

johnfoliot Jul 14, 2017

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Jul 21, 2017

Contributor

Hi David, John, Andrew, and all,

@DavidMacDonald

I can live with it.

@johnfoliot wrote:

I can live with this, with the provision that there will need to be some additional explanation in the Understanding documents that clearly explains the measurement criteria in detail.

Thank you, both very much. And John I agree it will need to be explained.

@awkawk Thank you, for integrating the text into the draft guidelines.

Laura

Contributor

lauracarlson commented Jul 21, 2017

Hi David, John, Andrew, and all,

@DavidMacDonald

I can live with it.

@johnfoliot wrote:

I can live with this, with the provision that there will need to be some additional explanation in the Understanding documents that clearly explains the measurement criteria in detail.

Thank you, both very much. And John I agree it will need to be explained.

@awkawk Thank you, for integrating the text into the draft guidelines.

Laura

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Jul 21, 2017

Contributor

Hi @alastc and all,

Now that the Adapting Text SC has passed the CFC and has been integrated into draft guidelines, Alastair, could you please update your bookmarklet with the metrics specified in the SC text so we can begin testing real world sites?

Previously I created a Wiki page for tracking results. I am wondering if it would it be better for tracking, if we have a table instead of lists. Any preferences?

I can create a new sister page to test and track VIP-PDF Reader results too.

Thank you!

Laura

Contributor

lauracarlson commented Jul 21, 2017

Hi @alastc and all,

Now that the Adapting Text SC has passed the CFC and has been integrated into draft guidelines, Alastair, could you please update your bookmarklet with the metrics specified in the SC text so we can begin testing real world sites?

Previously I created a Wiki page for tracking results. I am wondering if it would it be better for tracking, if we have a table instead of lists. Any preferences?

I can create a new sister page to test and track VIP-PDF Reader results too.

Thank you!

Laura

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Jul 22, 2017

Contributor

Hi Laura,

I've updated the script behind the bookmarklet, the best URL for the script is here:
https://alastairc.ac/tests/adaptation-scripts/scripts/text-adaptation.js

I was going to use github raw, but it doesn't use the right mimetype for JS and doesn't seem to work.

I would have thought a spreadsheet would be the best format for taking in results, e.g. a google spreadsheet, so long as the people testing are ok with that (I would be). It could be downloaded as an excel file and then rows could be copied in as a fall-back.

Contributor

alastc commented Jul 22, 2017

Hi Laura,

I've updated the script behind the bookmarklet, the best URL for the script is here:
https://alastairc.ac/tests/adaptation-scripts/scripts/text-adaptation.js

I was going to use github raw, but it doesn't use the right mimetype for JS and doesn't seem to work.

I would have thought a spreadsheet would be the best format for taking in results, e.g. a google spreadsheet, so long as the people testing are ok with that (I would be). It could be downloaded as an excel file and then rows could be copied in as a fall-back.

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Jul 24, 2017

Contributor

Hi Alastair and all,

@alastc wrote:

I've updated the script behind the bookmarklet, the best URL for the script is here:
https://alastairc.ac/tests/adaptation-scripts/scripts/text-adaptation.js

Thank you!

I would have thought a spreadsheet would be the best format for taking in results, e.g. a google spreadsheet, so long as the people testing are ok with that (I would be). It could be downloaded as an excel file and then rows could be copied in as a fall-back.

I can certainly create a google spreadsheet to track testing results. Is anyone not okay with that approach? Or would you prefer the Wiki? I can always copy the results from google sheets over to the Wiki later.

Thanks again,
Laura

Contributor

lauracarlson commented Jul 24, 2017

Hi Alastair and all,

@alastc wrote:

I've updated the script behind the bookmarklet, the best URL for the script is here:
https://alastairc.ac/tests/adaptation-scripts/scripts/text-adaptation.js

Thank you!

I would have thought a spreadsheet would be the best format for taking in results, e.g. a google spreadsheet, so long as the people testing are ok with that (I would be). It could be downloaded as an excel file and then rows could be copied in as a fall-back.

I can certainly create a google spreadsheet to track testing results. Is anyone not okay with that approach? Or would you prefer the Wiki? I can always copy the results from google sheets over to the Wiki later.

Thanks again,
Laura

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Jul 24, 2017

Contributor

Hello Everyone,

To ascertain how Google sheets may work for testing, I created a draft Adapting Text Testing Results Spreadsheet. Anyone with the link can view it.

Will this work?

Alastair, I gave you editing permissions. Does anyone else want to help test? If so, please let me know and I will give you permissions and you can give it a go.

Thank you,
Laura

Contributor

lauracarlson commented Jul 24, 2017

Hello Everyone,

To ascertain how Google sheets may work for testing, I created a draft Adapting Text Testing Results Spreadsheet. Anyone with the link can view it.

Will this work?

Alastair, I gave you editing permissions. Does anyone else want to help test? If so, please let me know and I will give you permissions and you can give it a go.

Thank you,
Laura

@goodwitch

This comment has been minimized.

Show comment
Hide comment
@goodwitch

goodwitch Jul 24, 2017

Contributor
Contributor

goodwitch commented Jul 24, 2017

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Jul 24, 2017

Contributor

Hi Glenda,

@goodwitch wrote:

I'm interested! Pick me! g

Thank you for volunteering! I have added you as an editor of the Adapting Text Testing Results Spreadsheet.

So far we have 2 tabs at the bottom of the spreadsheet.

The first tab is for testing HTML pages with Alastair's bookmarklet. To use it 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 second tab on the bottom of the spreadsheet is to collect data using VIP-PDF Reader.

The SC metrics to set in VIP-PDF Reader are:

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

Note: VIP-PDF Reader has no adjustment for spacing underneath paragraphs, so it seems we can't test that. Per the current SC text agreed to by the Working Group, spacing underneath paragraphs is supposed to be at least 2 times the font size.

Thanks again,
Laura

Contributor

lauracarlson commented Jul 24, 2017

Hi Glenda,

@goodwitch wrote:

I'm interested! Pick me! g

Thank you for volunteering! I have added you as an editor of the Adapting Text Testing Results Spreadsheet.

So far we have 2 tabs at the bottom of the spreadsheet.

The first tab is for testing HTML pages with Alastair's bookmarklet. To use it 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 second tab on the bottom of the spreadsheet is to collect data using VIP-PDF Reader.

The SC metrics to set in VIP-PDF Reader are:

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

Note: VIP-PDF Reader has no adjustment for spacing underneath paragraphs, so it seems we can't test that. Per the current SC text agreed to by the Working Group, spacing underneath paragraphs is supposed to be at least 2 times the font size.

Thanks again,
Laura

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Jul 25, 2017

Contributor

Hello Alastair, Glenda, and all,

I drafted some instructions in the Wiki for how to run Spacing tests for this SC:

Ideas for improvement? These probably can be worked into the Allowing for Spacing Override technique.

If anyone else would like to help test, please let me know and I'll add you as an editor of the Adapting Text Testing Results Spreadsheet. Thank again to @goodwitch , @alastc , and Alastair's colleague Amani.

Thanks,
Laura

Contributor

lauracarlson commented Jul 25, 2017

Hello Alastair, Glenda, and all,

I drafted some instructions in the Wiki for how to run Spacing tests for this SC:

Ideas for improvement? These probably can be worked into the Allowing for Spacing Override technique.

If anyone else would like to help test, please let me know and I'll add you as an editor of the Adapting Text Testing Results Spreadsheet. Thank again to @goodwitch , @alastc , and Alastair's colleague Amani.

Thanks,
Laura

@kerstinp

This comment has been minimized.

Show comment
Hide comment
@kerstinp

kerstinp Jul 25, 2017

Hi Laura,

depending on the PDF the VIP-Reader is opening a file with a warning, without a warning and it can also happen that it is not possible to open a file with VIP-Reader. For the interpretation of the results it is for sure helpful adding a column in the spreadsheet for these things. Especially when more PDF test cases will be added.

Does any of the PDF files in the list of test cases has one or more a file attachments? I can't say it for sure, but I think that VIP-Reader gives no information when file attachments are present.

Hi Laura,

depending on the PDF the VIP-Reader is opening a file with a warning, without a warning and it can also happen that it is not possible to open a file with VIP-Reader. For the interpretation of the results it is for sure helpful adding a column in the spreadsheet for these things. Especially when more PDF test cases will be added.

Does any of the PDF files in the list of test cases has one or more a file attachments? I can't say it for sure, but I think that VIP-Reader gives no information when file attachments are present.

@goodwitch

This comment has been minimized.

Show comment
Hide comment
@goodwitch

goodwitch Jul 25, 2017

Contributor
Contributor

goodwitch commented Jul 25, 2017

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Jul 25, 2017

Contributor
Contributor

mraccess77 commented Jul 25, 2017

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Jul 25, 2017

Contributor

I think in the email discussion we said to start with 1280px wide as per the zoom technique.

I suggest starting with 100% then:

  • test
  • reload
  • Zoom to 200%
  • test
  • reload
  • Zoom to 400%
  • test

I'm not certain it will make any difference, but it would be useful to know if doesn't make any difference!

Contributor

alastc commented Jul 25, 2017

I think in the email discussion we said to start with 1280px wide as per the zoom technique.

I suggest starting with 100% then:

  • test
  • reload
  • Zoom to 200%
  • test
  • reload
  • Zoom to 400%
  • test

I'm not certain it will make any difference, but it would be useful to know if doesn't make any difference!

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Jul 25, 2017

Contributor

Hi @kerstinp ,

Kerstin wrote:

depending on the PDF the VIP-Reader is opening a file with a warning, without a warning and it can also happen that it is not possible to open a file with VIP-Reader. For the interpretation of the results it is for sure helpful adding a column in the spreadsheet for these things. Especially when more PDF test cases will be added.

Good point. I added a column to the Adapting Text Testing Results Spreadsheet.

Does any of the PDF files in the list of test cases has one or more a file attachments? I can't say it for sure, but I think that VIP-Reader gives no information when file attachments are present.

None so far.

Thank you,

Laura

Contributor

lauracarlson commented Jul 25, 2017

Hi @kerstinp ,

Kerstin wrote:

depending on the PDF the VIP-Reader is opening a file with a warning, without a warning and it can also happen that it is not possible to open a file with VIP-Reader. For the interpretation of the results it is for sure helpful adding a column in the spreadsheet for these things. Especially when more PDF test cases will be added.

Good point. I added a column to the Adapting Text Testing Results Spreadsheet.

Does any of the PDF files in the list of test cases has one or more a file attachments? I can't say it for sure, but I think that VIP-Reader gives no information when file attachments are present.

None so far.

Thank you,

Laura

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Jul 25, 2017

Contributor

Hi @mraccess77 ,

Jonathan wrote:

We should also note the screen resolution used as well when zoom is used.

Thank you! I added a screen resolution column to the spreadsheet.

Laura

Contributor

lauracarlson commented Jul 25, 2017

Hi @mraccess77 ,

Jonathan wrote:

We should also note the screen resolution used as well when zoom is used.

Thank you! I added a screen resolution column to the spreadsheet.

Laura

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Jul 25, 2017

Contributor

Hi @goodwitch and @alastc,

Glenda wrote:

My question, when should I do the zooming? After I've run the bookmarklet
(and the line height, spacing underneath paragraphs, letter spacing and
word spacing has changed)? Or do I so the zoom to 200% and then 400% on a
"clean" version of the page?

I updated the Wiki page with Alastair's suggested procedure.

Thank you both very much!

Contributor

lauracarlson commented Jul 25, 2017

Hi @goodwitch and @alastc,

Glenda wrote:

My question, when should I do the zooming? After I've run the bookmarklet
(and the line height, spacing underneath paragraphs, letter spacing and
word spacing has changed)? Or do I so the zoom to 200% and then 400% on a
"clean" version of the page?

I updated the Wiki page with Alastair's suggested procedure.

Thank you both very much!

@kerstinp

This comment has been minimized.

Show comment
Hide comment
@kerstinp

kerstinp Aug 21, 2017

Hi @lauracarlson, one additional comment on the PDF-Tests with VIP-Reader: I think it is important to include PDF-Files in other languages, like arabic for example. These days I tried to open an arabic PDF with VIP-Reader. Please find the result in the screenshot attached. What I can't tell is if the VIP-Reader would display the text when the PDF would be accessible (whatever "accessible" means) and unfortunately I don't have any example for an arabic accessible PDF and in general no example for other languages than english and german. Therefore I can't say wether the problem is the technical quality of the PDF or the user agent.

arabic-pdf-vip

Hi @lauracarlson, one additional comment on the PDF-Tests with VIP-Reader: I think it is important to include PDF-Files in other languages, like arabic for example. These days I tried to open an arabic PDF with VIP-Reader. Please find the result in the screenshot attached. What I can't tell is if the VIP-Reader would display the text when the PDF would be accessible (whatever "accessible" means) and unfortunately I don't have any example for an arabic accessible PDF and in general no example for other languages than english and german. Therefore I can't say wether the problem is the technical quality of the PDF or the user agent.

arabic-pdf-vip

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Aug 21, 2017

Contributor

Hi @kerstinp ,

Thank you for your comment and attempt to test an Arabic PDF.

You wrote:

one additional comment on the PDF-Tests with VIP-Reader: I think it is important to include PDF-Files in other languages, like arabic for example. These days I tried to open an arabic PDF with VIP-Reader. Please find the result in the screenshot attached. What I can't tell is if the VIP-Reader would display the text when the PDF would be accessible (whatever "accessible" means) and unfortunately I don't have any example for an arabic accessible PDF and in general no example for other languages than english and german. Therefore I can't say wether the problem is the technical quality of the PDF or the user agent.

I'm not sure, Kerstin. Testing PDFs for this SC presents challenges.

Besides the international issue, VIP-PDF Reader has no adjustment for spacing underneath paragraphs. So that metric can't be tested. And it can be difficult to set a window size of 1280px by 768px for testing in VIP-PDF Reader. @mraccess77 previously asked about measuring viewport size for PDF readers for our tests. I used Free Ruler for the first 7. Check the VIP-PDF Reader Results tab in the spreadsheet. I included the VIP PDF-Reader's chrome but we may want to change that to just the content area.

Unless someone has a good idea for a PDF testing procedure for this SC (paging @awkawk ), one option would be, to not have this SC applicable to PDFs. From the work completed so far, it seems testing HTML documents for this SC may be more doable.

Thoughts everyone?

Contributor

lauracarlson commented Aug 21, 2017

Hi @kerstinp ,

Thank you for your comment and attempt to test an Arabic PDF.

You wrote:

one additional comment on the PDF-Tests with VIP-Reader: I think it is important to include PDF-Files in other languages, like arabic for example. These days I tried to open an arabic PDF with VIP-Reader. Please find the result in the screenshot attached. What I can't tell is if the VIP-Reader would display the text when the PDF would be accessible (whatever "accessible" means) and unfortunately I don't have any example for an arabic accessible PDF and in general no example for other languages than english and german. Therefore I can't say wether the problem is the technical quality of the PDF or the user agent.

I'm not sure, Kerstin. Testing PDFs for this SC presents challenges.

Besides the international issue, VIP-PDF Reader has no adjustment for spacing underneath paragraphs. So that metric can't be tested. And it can be difficult to set a window size of 1280px by 768px for testing in VIP-PDF Reader. @mraccess77 previously asked about measuring viewport size for PDF readers for our tests. I used Free Ruler for the first 7. Check the VIP-PDF Reader Results tab in the spreadsheet. I included the VIP PDF-Reader's chrome but we may want to change that to just the content area.

Unless someone has a good idea for a PDF testing procedure for this SC (paging @awkawk ), one option would be, to not have this SC applicable to PDFs. From the work completed so far, it seems testing HTML documents for this SC may be more doable.

Thoughts everyone?

@kerstinp

This comment has been minimized.

Show comment
Hide comment
@kerstinp

kerstinp Aug 22, 2017

Hi @lauracarlson,

just as a side comment: The testing note in cell K2 seems to be the testing note for the next document and should be placed in cell K3.

I think that there are more challenges than already mentioned in this thread, like how to decide if a failure is a user agent issue or an technology issue? I'm thinking about writing a comment as separate issue for this SC on github with one or two examples.

Some thoughts about "to not have this SC applicable to PDF": What about the old "concept" of "until user agents"? (Yes. I know that because of a lot of good reasons "until user agents" was abolished with WCAG 2.0.). If there would be a way bringing in the user agent instead of focusing the technology in this (and probably other) SC and specifically for PDF it seems to be much better than having one or more SC which are not applicable for PDF.

kerstinp commented Aug 22, 2017

Hi @lauracarlson,

just as a side comment: The testing note in cell K2 seems to be the testing note for the next document and should be placed in cell K3.

I think that there are more challenges than already mentioned in this thread, like how to decide if a failure is a user agent issue or an technology issue? I'm thinking about writing a comment as separate issue for this SC on github with one or two examples.

Some thoughts about "to not have this SC applicable to PDF": What about the old "concept" of "until user agents"? (Yes. I know that because of a lot of good reasons "until user agents" was abolished with WCAG 2.0.). If there would be a way bringing in the user agent instead of focusing the technology in this (and probably other) SC and specifically for PDF it seems to be much better than having one or more SC which are not applicable for PDF.

@lauracarlson

This comment has been minimized.

Show comment
Hide comment
@lauracarlson

lauracarlson Aug 22, 2017

Contributor

Hi @kerstinp ,

You wrote:

just as a side comment: The testing note in cell K2 seems to be the testing note for the next document and should be placed in cell K3.

Fixed. Thank you!

I think that there are more challenges than already mentioned in this thread, like how to decide if a failure is a user agent issue or an technology issue?

Agreed.

I'm thinking about writing a comment as separate issue for this SC on github with one or two examples.

Adding them to the Google spreadsheet would be another option to document the issues. Then the testing results would be in one place. If you would like, I can add you as an editor of the spreadsheet. Just let me know. After we gather a few more cases, I will Wiki-fi the table and and it to Results of VIP-PDF Reader Tests for Issue 78 as I did for the Results of Bookmarklet Tests for Issue 78.

Some thoughts about "to not have this SC applicable to PDF": What about the old "concept" of "until user agents"? (Yes. I know that because of a lot of good reasons "until user agents" was abolished with WCAG 2.0.). If there would be a way bringing in the user agent instead of focusing the technology in this (and probably other) SC and specifically for PDF it seems to be much better than having one or more SC which are not applicable for PDF.

If we can't find a good and reliable testing procedure for PDF UAs, perhaps we should consider adding something such as "and the user agent has the capability to adapt them" to the current text. So the SC could read something such as:

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

But I would like to get more cases documented and advice from @awkawk and the rest of the group first.

Thank you,
Laura

Contributor

lauracarlson commented Aug 22, 2017

Hi @kerstinp ,

You wrote:

just as a side comment: The testing note in cell K2 seems to be the testing note for the next document and should be placed in cell K3.

Fixed. Thank you!

I think that there are more challenges than already mentioned in this thread, like how to decide if a failure is a user agent issue or an technology issue?

Agreed.

I'm thinking about writing a comment as separate issue for this SC on github with one or two examples.

Adding them to the Google spreadsheet would be another option to document the issues. Then the testing results would be in one place. If you would like, I can add you as an editor of the spreadsheet. Just let me know. After we gather a few more cases, I will Wiki-fi the table and and it to Results of VIP-PDF Reader Tests for Issue 78 as I did for the Results of Bookmarklet Tests for Issue 78.

Some thoughts about "to not have this SC applicable to PDF": What about the old "concept" of "until user agents"? (Yes. I know that because of a lot of good reasons "until user agents" was abolished with WCAG 2.0.). If there would be a way bringing in the user agent instead of focusing the technology in this (and probably other) SC and specifically for PDF it seems to be much better than having one or more SC which are not applicable for PDF.

If we can't find a good and reliable testing procedure for PDF UAs, perhaps we should consider adding something such as "and the user agent has the capability to adapt them" to the current text. So the SC could read something such as:

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

But I would like to get more cases documented and advice from @awkawk and the rest of the group first.

Thank you,
Laura

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.