search

w3c / wcag21

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

Adapting text #78

Closed allanj-uaag closed 6 years ago

allanj-uaag commented 7 years ago

Current versions of SC and Definitions

Open Issues and Survey Results

(Links to surveys require W3C Member access)

SC Shortname

Adapting text

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

SC Text

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

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

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

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

Suggested Priority Level

Level AA

Related Glossary additions or changes

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

What Principle and Guideline the SC falls within.

Principle 1, Guideline 1.4

Description

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

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

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

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

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

Benefits

Font Family

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

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

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

Text Color

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

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

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

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

screen capture

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

screen capture

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

screen capture

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

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

Spacing

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

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

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

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

Some people need more space between letters to read text.

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

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

Some people need more space between words to read text.

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

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

Testability

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

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

Expected Results

Techniques

Existing Related Techniques

New Techniques

Related Information

Articles

Public and Member Comments

Research

Tests

Tools

Email

Minutes

GitHub

Wiki Pages

lauracarlson commented 7 years ago

Signing up as SC Manager for Issue 78.

lauracarlson commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

Hi @DavidMacDonald and @patrickhlauke,

Would Alastair's suggested SC text work for you?

Thanks, Laura

patrickhlauke commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

Thanks, @patrickhlauke .

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

goetsu commented 7 years ago

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 commented 7 years ago

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

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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.

On Sun, 8 Jan 2017 at 09:13 Patrick H. Lauke notifications@github.com wrote:

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?

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

patrickhlauke commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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.

WayneEDick commented 7 years ago

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

On Tue, Dec 20, 2016 at 4:58 AM, Laura Carlson notifications@github.com wrote:

@allanj-uaag https://github.com/allanj-uaag , @slhenry https://github.com/slhenry , and @WayneEDick https://github.com/WayneEDick your thoughts on whether this SC is a user agent issue and be should deferred to Silver? Please see David https://github.com/w3c/wcag21/issues/78#issuecomment-268033716's and Patrick https://github.com/w3c/wcag21/issues/78#issuecomment-268001666's comments.

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

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

WayneEDick commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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.

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 commented 7 years ago

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 commented 7 years ago

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

I’m not sure if this has changed – but in CSS Level 3 inheritance should be as follows:

An importanthttps://www.w3.org/TR/2013/CR-css-cascade-3-20131003/#important0 declaration takes precedence over a normal declaration. Author and user style sheets may contain !importanthttps://www.w3.org/TR/2013/CR-css-cascade-3-20131003/#important declarations, with user !importanthttps://www.w3.org/TR/2013/CR-css-cascade-3-20131003/#important declarations overriding author !importanthttps://www.w3.org/TR/2013/CR-css-cascade-3-20131003/#important declarations. This CSS feature improves accessibility of documents by giving users with special requirements (large fonts, color combinations, etc.) control over presentation.[1]

1 https://www.w3.org/TR/2013/CR-css-cascade-3-20131003/

Jonathan

patrickhlauke commented 7 years ago

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 commented 7 years ago

Hi All,

I put together a simple test case.

A spacing.css user stylesheet is available with Wayne's CSS declarations. Thanks @WayneEDick !

What results do people get? Does CSS specificity work in user agents as in the spec?

I tested in Safari and it respects user styles over author inline styles. Jon, the Stylish extension on chrome and Firefox didn't respect user styles over author inline styles for me. Do does it for you @mraccess77 ?

lauracarlson commented 7 years ago

@allanj-uaag tested in Internet Explorer. Thanks Jim! author inline !important is overridden by the user style sheet in IE.

@mraccess77 you are right the Stylish addon seems to apply the CSS at document level and not as a true user stylesheet. Thank you.

I updated the test page.

lauracarlson commented 7 years ago

I asked at the January 12, 2017 LVTF meeting if hard examples of where authors are breaking user styles can be provided.

allanj-uaag commented 7 years ago

Acrobat DC (not Acrobat reader) allows changes to line, character, and paragraph spacing, in editable PDFs. you can also change the font, font color, and font size. Caveat...the above changes work in a simple document. A complex form causes text overlap and other issues. Do spacing changes work? It depends on the document

DavidMacDonald commented 7 years ago

I think this is the current language.

The presentation of content does not interfere with the user agent's ability to allow the user to change foreground and background colors, font family​, ​or the spacing between characters, words, lines, or paragraphs​ to the element level, for the full range of values allowed by the user agent​, for the technology chosen for the content.

We could roll in the printing SC into this #76 by adding "...and to print the document with these changes."

mbgower commented 7 years ago

We could roll in the printing SC into this #76 by adding "...and to print the document with these changes."

+1

lauracarlson commented 7 years ago

Hi @DavidMacDonald ,

That text seems to be proposal 5 on the Combine 79, 78, 74 Wiki page. It might fit in there.

However, the latest version we have is proposal 18. I don't know how we could fit it in there.

We will likely discuss at tomorrow's LVTF meeting, if you are available.

mraccess77 commented 7 years ago

I'd like to caution combing two things that sounds similar but may be independent together. I'm not sure if this is the case here or not. But when people flag SC we want to be able to precisely indicate the issue. For example, if the SC passed for on-screen but failed for printing we would be force to faill the whole SC even though it worked correctly on-screen. Given that printing is a lower priority to some --- failing the whole SC doesn't make sense and it should be separate.

lauracarlson commented 7 years ago

Hi @allanj-uaag and @slhenry ,

Jim wrote:

Acrobat DC (not Acrobat reader) allows changes to line, character, and paragraph spacing, in editable PDFs. you can also change the font, font color, and font size. Caveat...the above changes work in a simple document. A complex form causes text overlap and other issues. Do spacing changes work? It depends on the document

@GreggVan asked several questions with regard to level in the Combine 79, 78, and 74 SCs thread. i.e. Are Acrobat DC and VIP PDF free browser plug ins. If they are do any videos demonstrating these products exist?

GreggVan commented 7 years ago

also Acrobat DC is expensive — no? so users will not have it ?

gregg

On Jan 25, 2017, at 1:40 PM, Laura Carlson notifications@github.com wrote:

Hi @allanj-uaag https://github.com/allanj-uaag and @slhenry https://github.com/slhenry ,

Jim wrote:

Acrobat DC (not Acrobat reader) allows changes to line, character, and paragraph spacing, in editable PDFs. you can also change the font, font color, and font size. Caveat...the above changes work in a simple document. A complex form causes text overlap and other issues. Do spacing changes work? It depends on the document

@GreggVan https://github.com/GreggVan asked several questions with regard to level in the Combine 79, 78, and 74 SCs thread https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JanMar/0355.html. i.e. Are Acrobat DC and VIP PDF free browser plug ins and if are there any videos demonstrating these products.

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

allanj-uaag commented 7 years ago

correct, Acrobat Pro DC is expensive. VIP-PDF is free.

VIP-PDF reader video http://snab.ch/en/hilfsmittel/digital-tools/the-first-pdf-reader-for-visually-impaired-people/

On Wed, Jan 25, 2017 at 12:43 PM, GreggVan notifications@github.com wrote:

also Acrobat DC is expensive — no? so users will not have it ?

gregg

On Jan 25, 2017, at 1:40 PM, Laura Carlson notifications@github.com wrote:

Hi @allanj-uaag https://github.com/allanj-uaag and @slhenry < https://github.com/slhenry> ,

Jim wrote:

Acrobat DC (not Acrobat reader) allows changes to line, character, and paragraph spacing, in editable PDFs. you can also change the font, font color, and font size. Caveat...the above changes work in a simple document. A complex form causes text overlap and other issues. Do spacing changes work? It depends on the document

@GreggVan https://github.com/GreggVan asked several questions with regard to level in the Combine 79, 78, and 74 SCs thread < https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JanMar/0355.html>. i.e. Are Acrobat DC and VIP PDF free browser plug ins and if are there any videos demonstrating these products.

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

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

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

GreggVan commented 7 years ago

Does VIP-PDF provide variable line word character spacing ? Does it also allow reflow when you enlarge text?

If so that would be great

Gregg

Sent from my iPad

On Jan 25, 2017, at 5:20 PM, allanj-uaag notifications@github.com wrote:

correct, Acrobat Pro DC is expensive. VIP-PDF is free.

VIP-PDF reader video http://snab.ch/en/hilfsmittel/digital-tools/the-first-pdf-reader-for-visually-impaired-people/

On Wed, Jan 25, 2017 at 12:43 PM, GreggVan notifications@github.com wrote:

also Acrobat DC is expensive — no? so users will not have it ?

gregg

On Jan 25, 2017, at 1:40 PM, Laura Carlson notifications@github.com wrote:

Hi @allanj-uaag https://github.com/allanj-uaag and @slhenry < https://github.com/slhenry> ,

Jim wrote:

Acrobat DC (not Acrobat reader) allows changes to line, character, and paragraph spacing, in editable PDFs. you can also change the font, font color, and font size. Caveat...the above changes work in a simple document. A complex form causes text overlap and other issues. Do spacing changes work? It depends on the document

@GreggVan https://github.com/GreggVan asked several questions with regard to level in the Combine 79, 78, and 74 SCs thread < https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JanMar/0355.html>. i.e. Are Acrobat DC and VIP PDF free browser plug ins and if are there any videos demonstrating these products.

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

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

-- Jim Allan, Accessibility Coordinator Texas School for the Blind and Visually Impaired 1100 W. 45th St., Austin, Texas 78756 voice 512.206.9315 fax: 512.206.9264 http://www.tsbvi.edu/ "We shape our tools and thereafter our tools shape us." McLuhan, 1964 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

allanj-uaag commented 7 years ago

change foreground/background font family (9 to choose from) line, word, character spacing. zoom with reflow

On Wed, Jan 25, 2017 at 8:23 PM, GreggVan notifications@github.com wrote:

Does VIP-PDF provide variable line word character spacing ? Does it also allow reflow when you enlarge text?

If so that would be great

Gregg

Sent from my iPad

On Jan 25, 2017, at 5:20 PM, allanj-uaag notifications@github.com wrote:

correct, Acrobat Pro DC is expensive. VIP-PDF is free.

VIP-PDF reader video http://snab.ch/en/hilfsmittel/digital-tools/the-first-pdf- reader-for-visually-impaired-people/

On Wed, Jan 25, 2017 at 12:43 PM, GreggVan notifications@github.com wrote:

also Acrobat DC is expensive — no? so users will not have it ?

gregg

On Jan 25, 2017, at 1:40 PM, Laura Carlson <notifications@github.com

wrote:

Hi @allanj-uaag https://github.com/allanj-uaag and @slhenry < https://github.com/slhenry> ,

Jim wrote:

Acrobat DC (not Acrobat reader) allows changes to line, character, and paragraph spacing, in editable PDFs. you can also change the font, font color, and font size. Caveat...the above changes work in a simple document. A complex form causes text overlap and other issues. Do spacing changes work? It depends on the document

@GreggVan https://github.com/GreggVan asked several questions with regard to level in the Combine 79, 78, and 74 SCs thread < https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JanMar/0355.html>. i.e. Are Acrobat DC and VIP PDF free browser plug ins and if are there any videos demonstrating these products.

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

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

-- Jim Allan, Accessibility Coordinator Texas School for the Blind and Visually Impaired 1100 W. 45th St., Austin, Texas 78756 voice 512.206.9315 <(512)%20206-9315> fax: 512.206.9264 <(512)%20206-9264> http://www.tsbvi.edu/ "We shape our tools and thereafter our tools shape us." McLuhan, 1964 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

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

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

lauracarlson commented 7 years ago

Thanks @allanj-uaag . I downloaded VIP-PDF. It seems to work great.

@GreggVan , VIP-PDF is a desktop application; not a browser plugin. So will we need Wayne's disclaimer and scope it to HTML and let PDF off the hook? @WayneEDick 's disclaimer text is:

"If no mechanism exists to overide spacing, font family or text color on any user agent for the target technology, then the author has no responsible to create one."