Spacing Override Technique

[allanj-uaag]

+1 https://github.com/w3c/wcag/blob/tech-spacing-override/techniques/css/spacing-override.html

[emanser]

+1 to https://github.com/w3c/wcag/blob/tech-spacing-override/techniques/css/spacing-override.html

[goodwitch]

+1 to https://github.com/w3c/wcag/blob/tech-spacing-override/techniques/css/spacing-override.html

[johnfoliot]

+1

JF

On Tue, Jun 26, 2018 at 1:25 PM, Glenda Sims notifications@github.com wrote:

+1 to https://github.com/w3c/wcag/blob/tech-spacing-override/ techniques/css/spacing-override.html

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag/issues/384#issuecomment-400415805, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-c1fKF3NGWZiid_PiGXpRlrnWnhGsks5uAnyygaJpZM4U4LCO .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion

[stevefaulkner]

+1

[alastc]

This ran into issues on the call, people thought it needed to be a positive technique rather than a place to put the test procedure.

I've had a run at making it into a technique for small containers (we'll need one for not applying a height to containers of wrapping text).

Preview on rawgit: https://rawgit.com/w3c/wcag/tech-spacing-override-ac/techniques/css/spacing-override-small.html

Quick live example: https://rawgit.com/w3c/wcag/tech-spacing-override-ac/techniques/css/example-text-spacing/ (Not sure we need that, I was just checking it worked.)

It's a bit rough, but does the general direction seem ok?

[lauracarlson]

Hi @alastc ,

Thank you, Alastair! Good examples.

On the call @awkawk had mentioned that he would prefer not having separate technique documents for this. So should I incorporate your examples into our original Allowing for text spacing override doc?

I have already tried to incorporate the other survey comments.

Thanks again.

[alastc]

Hi @lauracarlson,

I think the point was that it should have a positive technique, and a thing to do, rather than be the housing for the test-procedure. And, it's ok to have the same procedure in more than one techinque.

So if we split the small-boxes and wrapping examples, that becomes two techniques with the same test.

If this one looks ok, we can duplicate and create a variation for blocks with wrapping text.

[lauracarlson]

Hi @alastc and all,

Thank you for our discussion on the LVTF call today. As agreed, I incorporate your 2 examples into our original Allowing for text spacing override doc.

I also added a third example with a live demo. Please check it out and let me know if anything should be changed/improved.

Much appreciated, Laura

[mbgower]

One thing I'm wondering about. My recollection is that we arrived at the SC spacing requirements because we wanted something measurable/testable, and it was felt that achieving these meant that the page was malleable enough to allow for other adaptations of text. However, this technique (which essentially is just leaving a buffer space in containers) may not accommodate, for instance, someone choosing a font with a wide em value in addition to expanding the kerning. So while I think this technique will achieve the (ahem) 'letter' of the SC, I'm not sure it is as scalable as hoped.

I also wonder about step 4 "Check that all content and functionality is available." I'm wondering if that needs to be a bit more precise, e.g., Check that text is not truncated, especially within containers. etc.

[lauracarlson]

Hi @mbgower,

Thank you for the comment. Much appreciated.

I tried to make the last step more precise. It now reads:

Check that all content and functionality is available e.g., text in containers is not truncated and does not overlap other content.

Does that do it?

I agree that the SC metrics were a compromise. Perhaps we can do better with Silver.

[lauracarlson]

Hi @alastc, @awkawk, @mbgower and all,

I have been thinking about Andrew's and Mike's comments at the July 17, 2018 telco.

Do we want to:

1. Break this technique into 3 separate techniques

Mike suggested in the telco and on the survey to add a qualifying paragraph in the understanding document and list the 3 techniques there. For instance:

Sufficient Techniques

Ensuring that no loss of content or functionality occurs when text spacing is overridden by using one or more of the following techniques:

• A box sized with space to allow for expansion
• A box which expands with the text size
• A paragraph expands vertically within container

2. Keep the 3 examples in this one technique and try to explain better what authors should do.

For instance, maybe replace the current description which is:

Current

Description

The objective of this technique is to allow a user to override text spacing via user stylesheet, bookmarklet, extension, or application. Increased spacing between paragraphs, lines, words, and characters benefits people with low vision or some cognitive disabilities. Content needs to allow spacing changes without loss of content or functionality.

Containers must be able to expand. Small areas of text (such as navigation bars) need to have sufficient space within each box so that words and characters do not expand out of their containers. Paragraphs need to allow text to increase vertically for languages or scripts such as English which are read horizontally or to increase horizontally for languages or scripts which are read vertically.

With something such as:

Attempt at improvement

Description

The objective of this technique is to allow a user to override text spacing via user stylesheet, bookmarklet, extension, or application. Increased spacing between paragraphs, lines, words, and characters benefits people with low vision or some cognitive disabilities. Content needs to allow spacing changes without loss of content or functionality. Containers must be able to expand.

Authors should size containers to a have a value greater than the default width of the text. Small areas of text (such as navigation bars) need to have sufficient space within each box so that words and characters do not expand out of their containers.

Authors can take advantage of the inline-block value of the CSS display property and not set negative margins to help allow for spacing overrides. HTML elements with inline-block values are white space dependent. They react to adjacent white space and leave a space, if a space is present in the markup. Containers will automatically wrap if the area becomes too crowded. Not setting negative margins on can also help ensure content does not overflow containers.

In English languages, if authors do not set the CSS height property, it can help ensure paragraphs expand. Paragraphs need to allow text to increase vertically for languages or scripts such as English which are read horizontally or to increase horizontally for languages or scripts which are read vertically.

3. Delete the technique

Put the testing procedure in the Understanding Document and not have a specific technique(s).

Which do you prefer?

Thoughts on how to proceed? Do you prefer number 1, 2, or 3? Other ideas?

Thanks everyone!

[mbgower]

Hi Laura, I almost feel there is wording sitting in 1.4.4 Resize Text's technique from number 4:

Ensuring that text containers resize when the text resizes AND using measurements that are relative to other measurements in the content by using one or more of the following techniques:

What about "G### Ensuring that text containers resize when text resizes" and possibly G### Using measurements relative to other measurements"

The text could just be portions of what you've written, glued together, for instance:

In order to allow users to alter text spacing, text containers must be able to expand.

Authors should size containers to have a value greater than the default width of the text. Small areas of text (such as navigation bars) need to have sufficient space within each box so that words and characters do not expand out of their containers.**

For your bullets, I was thinking you could reuse many of the same techniques from 1.4.4 here:

C28: Specifying the size of text containers using em units (CSS)

Techniques for relative measurements

    C12: Using percent for font sizes (CSS)

    C13: Using named font sizes (CSS)

    C14: Using em units for font sizes (CSS) 

Techniques for text container resizing

    SCR34: Calculating size and position in a way that scales with text size (Scripting)

    G146: Using liquid layout 

Note that those are all CSS techniques except for SCR34. So I think one thing you could do is just consider making a CSS technique, rather than a general one. Alternatively, you could just regurgitate G146, which seems like a CSS technique masquerading as a general techniqu.

[lauracarlson]

Hi @mbgower, @alastc, @awkawk, and all,

Thanks, Mike!

@alastc, @awkawk, and everyone else, do you agree with Mike's (ala 1.4.4) approach ?

If we go that route (having a preamble in the Understanding Doc and listing techniques already in existence), what do we do with the test procedure? Add it to the Understanding Doc?

Thanks, Laura

[mbgower]

Just to clarify @lauracarlson , I was suggestion you could lift the language from 1.4.4. So I'm suggesting making the technique be called: G### Ensuring that text containers resize when text resizes

[awkawk]

@alastc @mbgower @lauracarlson I added a paragraph example to alastair's example file (https://rawgit.com/w3c/wcag/tech-spacing-override-ac/techniques/css/example-text-spacing/).

In Safari it seems to have problems when using stylish to change the text properties:

I'm not sure what people experience in other browsers.

[alastc]

Odd, it works fine in FF & Chrome in stylus, I can't see why the second para would be different from the 1st either!?

[awkawk]

not sure - I was getting buggy results - sometimes all paragraphs, sometimes just one. I originally set it to 25% width for the div but that was buggy too, so not sure what we would recommend.

[alastc]

I can't find stylish to install in Safari, but I get similar behaviour in Freestyler(.ws) so it could be an issue with Safari rendering changes from extensions. I've pinged a question to someone from Apple on twitter, not exactly sure who to ask so that was my first question.

Also, if you apply the styles via a bookmarklet they all break out of the containers, but if you go back a page and then forward (so it re-renders without re-loading), the spacing is applied and they fit in the containers.

It appears Safari is not very confortable with applying styles after the initial page render.

However, if you apply it via a user stylesheet (which Safari still supports!) then it works fine. (Save the styles in a CSS file, then in Safari's settings, Advanced tab, there's a drop-down with 'other' to choose your stylesheet.)

[lauracarlson]

I think Alastair is right. A user stylesheet in Safari with the metrics from the SC works fine.

The bookmarklet in Safari is wonky though too. See attached screenshot:

Laura

On 8/6/18, Alastair Campbell notifications@github.com wrote:

I can't find stylish to install in Safari, but I get similar behaviour in Freestyler(.ws) so it could be an issue with Safari rendering changes from extensions. I've pinged a question to someone from Apple on twitter, not exactly sure who to ask so that was my first question.

Also, if you apply the styles via a bookmarklet they all break out of the containers, but if you go back a page and then forward (so it re-renders without re-loading), the spacing is applied and they fit in the containers.

It appears Safari is not very confortable with applying styles after the initial page render.

However, if you apply it via a user stylesheet (which Safari still supports!) then it works fine.

-- Laura L. Carlson

[alastc]

Going back to the question of what-next, we could take the 1.4.4 approach with a general technique statement such as:

Ensure containers allow for increase text-spacing

Each of the techniques from 1.4.4 have a test, but the CSS ones are "check this unit is used", and the general one has a test procedure that is aimed at 1.4.4.

I think we still need new general techniques based on the drafted one, so I'm leaning towards Laura's "1. Break this technique into 3 separate techniques"

Except that of those 3 techniques, only 1 & 3 are valid. I don't think 2, "boxes expanding with text size" helps for this SC. (Boxes can expand with text-size/zoom, but I don't know of a mechanism to increase a container based on letter/word spacing the user applies.)

Reviewing the techniques that could be included, the only "sufficient with" technique I'd include is: G179 Ensuring that there is no loss of content or functionality when the text resizes and text containers do not change their width.

The ones @mbgower listed could be in the related list, but I don't think any help this SC in a way that is sufficient.

So perhaps:

Ensure containers allow for increase text-spacing:

• Gxxx Ensuring that there is no loss of content or functionality when text-spacing is increased for blocks of text (our block-level one)
• Gxxx Ensuring that there is no loss of content or functionality when text-spacing is increased for containers that do not permit text-wrapping (the small-blocks one)
• G179 Ensuring that there is no loss of content or functionality when the text resizes and text containers do not change their width

Those apply to different content containers, but the test procedure could be the same for each, just starting slightly differently depending on the content. E.g. "For each element that contains blocks of text:"

[alastc]

Ok, I'll try and get this one moving again.

I've separated this into two techniques now, see the desc for the links.

My question is: Does the one aimed at wrapping content make sense, or should that be a failure instead?

[lauracarlson]

Hi @alastc ,

I don't think that separating it into 2 techniques was the issue @awkawk was having with it. But it can't certainly can't hurt :-) I had been waiting for Andrew's review.

The technique aimed at wrapping content make sense to me. Thanks!

[lauracarlson]

Hi @alastc , @awkawk

I think this issue can be closed now as we now have following in the 1.4.12: Text Spacing Understanding Doc:

• C36: Allowing for text spacing override
• C35: Allowing for text spacing without wrapping

The Techniques Spreadsheet could also be updated with the 2 techniques too.

Thanks, Laura

[awkawk]

Thanks @lauracarlson - I updated the spreadsheet and will close this issue.