Comments: Issue 78 "Spacing"

Not Mature

Not Mature. User Agent issue.

My concern is that this really is a User agent issue.

David's spreadsheet and GitHub - 268033716

19 December 2016

Unsupported in Mobile

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.

12 January 2017

12 January 2017

Other have pointed out the technical limitations for some user agents

Maybe we can consider that Internet Explorer has this feature because it let user specify a user style sheet without any plugin or extension.

Customization personalization

GitHub - 268033716

14 January 2017

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?

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

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 interfere with that support.

...

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.

Asked for "ideal" user stylesheet.

Asked for example of where !important can't be overwritten by users.

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 5 January 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?

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

User stylesheet supported: IE & Safari. Plugin needed for Firefox & Chrome

!important user styles takes precedence over author styles

Sample "ideal" user stylesheet needed for consistent testing

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.

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

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.

...

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.

When UAs user allow for user CSS those can override author CSS.

3rd party plug-ins and bookmarklets don't override author CSS so "important" may not be able to be overwritten.

this is not a problem of priority, but rather of CSS specificity and cascade.

Author CSS with higher specificity in its selector overrides user CSS with a lower specificity.

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.

Safari and IE: respects user styles over author inline styles.

Stylish extension: does not respect user styles over author inline styles

I put together a simple test case.

A spacing.css user stylesheet is available with Wayne's CSS declarations.

GitHub - 271425624 and GitHub - 272233033

need to be able to swap out stylesheets.

SC vs what is available. or what can be done today.

we want authors to not prevent users from changing their content to meet their needs

User CSS is a poor mechanism.

Investigating javascript solution

user styles are a poor way of fixing author styles.
... been experimenting with using javascript to apply user styles.
... line length - when the user puts max-width by whatever mechanism, what do authors need to do to not break the user demand
... the question is "what are we asking authors to do"
... back to question.... not much of a limitation. the issues is frameworks, extra plugins, server side styles, etc.
... authors are writing very specific styles for get around the plethora of css in use. which makes it hard for users to override styles

https://alastairc.ac/tests/layouts/percentages-rwd.html

links can work as bookmarklet to work on any site.

because it is javascript it can be more selective

need to rephrase for things the author can do, not what user overrides.

5 January 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.

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

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

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

I agree we must have an exception if the UA doesn't have a feature to let user change spacing adjustments

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

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

<shawn> [ Shawn is not cool with that exception ]

<shawn> Content is not accessible if users cannot change line spacing

...

what about alistairs language to not get in the way of CSS.
... can we propose spacing without the exception. it can be met automatically by html unless you use !important at page level element.

12 January 2017

14 January 2017

I think that the LVTF should support SC's for spacing and font-family even if we cannot come up with an example of HTML that does not allow a JavaScript modification.

The reason is this. This level of support should have been part of 1.3.1. It wasn't because WCAG WG used an intersection model. if a necessary accommodation was not supported by all technologies, we could not make an SC blocking certain authoring techniques.

Our language lets the author off the hook on a platform or in a file language that can't support the change. This is a union model. If there is one user agent that supports the feature then authors must write design their page so that it does not conflict with that support. We can even say one commonly used agent.

This model means that we should combine our techniques into one, so that a person can get feature x only on browser A but needs to go to browser B for feature y.

16 January 2017

Non-trivial and onerous for AA, and even AAA

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

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.