Comment Summary 1-4-13
The propose of this page is to collate comments for the Adapting Text SC 1.4.3 that Andrew listed in his November 6, 2017 email, draft proposed responses, and incorporate any changes if needed into the SC text.
SC Text
| Current SC text in draft | Proposed SC text after November 13 meeting and subsequent on list discussion thread 368 and discussion thread 397 |
|---|---|
| Success Criterion 1.4.13 Adapting 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:
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. |
Success Criterion 1.4.13 Text Spacing
If the technologies being used allow the user agent to set text style properties, then no loss of content or functionality occurs by setting all of the following and by changing no other style property:
Editor's note: The Working Group seeks examples in the wild of text content outside of blocks of text where it would be impossible to meet this SC. The SC's scope may be narrowed based upon implementation testing. |
Summary of Proposed Changes
- SC name change per Issue 418
- Reworded opening clause of the SC to remove the word "adapt" and its definition per issue #409
- Removed the editor's note regarding color and font per Issue #153
- Removed the note per WG Discussion on the November 13, 2013 call. Will be addressed in the understanding document. (Issues 438 and 347)
- Removed the word "essential" per Issue 372
- Reworded to remove loophole per Issue 577
- Added Editor's note regarding implementation testing per Issues 469, 551, and 576
Public Comments
Issue 551: restrict to blocks of text?
Could this be restricted to blocks of text as opposed to text in UI - (e.g. menus, etc.)? @JanRichards, October 14, 2017
Proposed Response
Thank you for your comment.
Based on an evaluation of 67 pages tested between July 25 and August 3, 2017 that included top 50 Alexa pages and some smaller pages, the combined metrics specified in the Adapting Text SC should be feasible in WCAG 2.1 for HTML documents. Spacing is able to adapt without loss of content or functionality across a wide range of sites.
The Working Group will be going through the implementation process and demonstrating the implementability of all the new SCs. If you know of examples in the wild of text in UI - (e.g. menus, etc) where it would not be possible to meet the SC, please add them to this issue.
We are tagging this issue with the "Implementation Follow-up" label to ensure that it is re-reviewed at that point in our process. In addition we will add the following editor's note:
"Editors Note: The Working Group seeks examples in the wild of text content outside of blocks of text where it would be impossible to meet this SC. The SC's scope may be narrowed based upon implementation testing."
Issue 469: Concern that it is too hard to test
I see the benefits but I do not think it is practical to implement, especially outside of the main content area with blocks of text. It would very hard to support in navigation, custom widgets and some types of forms.
Would the combinations of these need to be supported? (eg line spacing, letter spacing and word spacing all modified) there are many permutations and combinations to account.
Even the basic 4 listed items would be very hard to test. - @AidanA11y, October 14, 2017
Proposed Response
Thank you for your comment.
Based on an evaluation of 67 pages tested between July 25 and August 3, 2017 that included top 50 Alexa pages and some smaller pages, the combined metrics specified in the Adapting Text SC should be feasible in WCAG 2.1 for HTML documents. Spacing is able to adapt without loss of content or functionality across a wide range of sites.
The Working Group will be going through the implementation process and demonstrating the implementability of all the new SCs. If you know of examples where it would not be possible to meet the SC, please add them to this issue.
We are tagging this issue with the "Implementation Follow-up" label to ensure that it is re-reviewed at that point in our process. In addition we will add the following editor's note:
"Editors Note: The Working Group seeks examples in the wild of text content outside of blocks of text where it would be impossible to meet this SC. The SC's scope may be narrowed based upon implementation testing."
Issue 418: needs name change or to be in different GL?
Just a question: Is it not confusing for people when the name of SC 1.4.13 is "Adapting" text and the SC is not part of Guideline 1.3 Adaptable but belongs to 1.4 Distinguishable? - @kerstinp, October 5, 2017
Proposed Response
Thank you for your comment. You raise a good point and we agree that it may be confusing.
Now that the WG decided to remove the note regarding color and font from the SC per Issue #153, we agree that narrowing the name is appropriate. The goal of making the title contextual is a good practice. We will change this SC's title to "Text Spacing" so it better matches its scope.
Issue 409: “client” used in SC but “user agent” used in SC
In the glossary entry the term "client" is used but in the SC 1.4.13 the term "user agent" is used which can be something different. - @kerstinp, October 5, 2017
Proposed Response
Thank you for your comment.
We have updated the SC language. It no longer uses the definition for "adapt", so this issue is resolved.
Member Comments
Issue 438: suggestion on rewording for the note
For clarity, and to match the language used in the SC, IBM recommends altering the Note to read:
Examples of technologies that do not allow the user agent to adapt style properties are open captions and images of text, which are not expected to adapt. - @mbgower, IBM comment, October 8, 2017
Proposed Response
Thank you for your comment. The SC note has been remove per WG Discussion on the November 13, 2013 call. We will be addressing captions and images of text in the understanding document.
Issue 390: i18n concerns
Is the content author going to allow the user to apply a fixed tracking distance for all text? I imagine this would be better applied as a multiplier or addition for current tracking.
One reason for this is that i am told that tracking is used in German as a method of emphasis (eg. rather than english italicisation). If you make the tracking for a spaced-out word the same as the surrounding text, the reader would loose a presentational feature that is meaning-related.
Also, there's a question of whether this will affect ligation (eg. fi ligatures) by separating them?
I also have questions about how this woud apply to other scripts.
Arabic, Assyrian, Mongolian, and N'Ko, for example, are cursive scripts (ie. the letters join). Again, for Arabic, baseline stretching is often used for emphasising text, for making headings or signage more visible, or for matching the length of adjoining lines of text, etc. When the baseline is stretched, moreover, there are fairly complicated rules about where the stretching is and isn't allowed. I don't believe this is yet covered by the letter-spacing property in CSS.
In other complex scripts, such as Devanagari (used for Hindi), certain combinations of characters combine together, and it's not clear to me how tracking is applied but it's clear that it's not between each character. If the user is applying the tracking via a CSS property change, that may take care of many of the issues, but not clear to me yet whether all.
Also, is the 0.12 multiplier based on research on English text or on a variety of scripts? If the former, the spec should probably call that out.
And finally, the text may already have positive or negative tracking set using CSS. Presumably that setting should be taken into account when adding addition space, rather than just basing the ratio on the font size. - @r12a, September 21, 2017
Proposed Response
Thank you for your comment.
The intent of this Success Criterion is to help ensure that people with disabilities who override spacing can read text. It allows for a spacing buffer. Applying that buffer is under the user's control.
As @mraccess77 (Jon Avala) stated changes can be made via user style sheets implemented or customized by the user. A bookmarklet has also been developed. As Jon stated the SC does not dictate that authors must set all their content to the specified metrics. Rather, it specifies that an author's content has the ability to be set to those metrics without the loss of content or functionality. The author requirement is to not to interfere with a user's ability to override the author settings.
We have called out the basis for the SC's metrics in the Understanding Document and link to the actual studies in the resources section. If you can provide specific examples of where this would be a problem that would be helpful in our implementation review.
Issue 389: font-family changes would need to consider i18n
Font-family adaptations would need to be sensitive to language changes. A page containing text in both english and hindi would not necessarily become more readable if a user-defined english font was applied to all the hindi text too (and vice versa). - @r12a, September 21, 2017
Proposed Response
Thank you for your comment.
The WG decided to remove the font family bullet from the SC per Issue #153.
Issue 388: line height / para spacing i18n concerns
Such changes should produce multiples or additions to existing line heights/leading, particularly where a page contains multiple languages. For example, Thai or Tibetan text needs much larger line heights relative to font size than english. If the line height of the english is bumped up, that of the thai and tibetan text should also be increase pro rata – it should certainly not be reduced to match the english. - @r12a, September 21, 2017
Proposed Response
Thank you for your comment.
As @steverep said, the criterion does say "at least", so there is no need to reduce line height to test the condition.
You are correct that basing the line-height and leading on the font size will have different effects, depending on the font used. The current metrics were chosen as measures based on Research. McLeish ran from .04 to .25 em tests. 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. Wayne E. Dick, Ph.D. analyzed the McLeish study and translated from points. Dr. Dick recommended the metrics that the Working Group adopted.
If you know of international research that impacts the current metrics please add them to this issue. As Steve said we could give different numbers for different languages if needed.
Issue 349: Perhaps restrict to CSS?
This provision requires that authors not interfere with user agents that allow style properties to be adapted. This would require the author to know exactly how every single different type of user agent might support styles. That is, they would be required to not interfere with something that they had no idea existed or how it worked
SOLUTION We might approach this in one of two ways
- you might restrict this to just CSS
- you might restrict this to common browsers or the most common browsers or something like that.
If you're really just worried about CSS you might however just restricted to that. - @GreggVan, Aug 31, 2017
Proposed Response
As @steverep stated, the Web technology is providing the allowance for this SC, not the user agent. HTML/CSS/JavaScript is included because they are passed as text to the user agent and thus can be modified.
The author only need be familiar with the technologies they are using and whether or not support exists for adapting styles once content is transferred to the user agent, which will all be covered in the Understanding document like other technology specific capabilities and techniques. Moreover, how all possible user agents render a technology is not something WCAG expects authors to know with regard to any criterion. Rather, they only need know that the technology can combine with a user agent and meet the definition of accessibility supported.
Issue 347: suggests “OPEN” captions in the exception
I would include the word OPEN in your link regarding captions. As it is currently written here I focuses on the word captions and it looks like all captions are excepted when in fact you mean to only except OPEN CAPTIONS.
SOLUTION - just include the word open and the link so that the link is OPEN CAPTIONS even if the link jumps to a general definition of captions that has open captions discussed in it. - @GreggVan, Aug 31, 2017
Proposed Response
Thank you for your comment. The SC note has been remove. We will be addressing captions and images of text in the understanding document.
Issue 372: Use of "essential"
Some SC use the word "essential" and reference a term which provides a specific definition. Other SC use the word "essential" and do not reference that term. In such a case one might think the term should be referenced, yet the definition doesn't seem targeted to the meaning of the word in all SC. I think we need to do one of the following:
- Adjust the definition of "essential" to be appropriate to all SC that use the word, then reference the term consistently;
- Use a different word in place of "essential" for which the current term is not appropriate.
Proposed Response
Thank you for your comment. The Working Group will be removing the word "essential" from the SC text.
As steverep said, the word essential: "seems to have been introduced by @awkawk in a comment way back in March, but I could not find any rationale for its inclusion in the language (i.e. an example of content loss that would be acceptable). Given this, and the fact that both Resize Text and Zoom Content refer to "loss of content or functionality" without using essential, I propose to simply remove the word from this SC."
And as Jason White, has stated, leaving "essential" in risks making the SC not being reliably testable. By removing it accessibility is enhanced.
Issue 576: Change adapting text to "blocks of text"
We've had 2 reputable commenters who are veteran full time accessibility professionals and testers, ask that this SC get changed to "Blocks of Text", Jan Richards of the IDRC, and Aiden from TD Bank.
I'd like to add my voice to that concern. I was the author of SC 1.4.8 in WCAG 2.0. And the "blocks of text" language was carefully negotiated, I never could have got through without that. I think we should carefully consider "Blocks of Text". Without that, there are a lot of variables, and possible confusion. It might become a stumbling block for the SC in CR.
Proposed Response
Thank you for your comment.
Based on an evaluation of 67 pages tested between July 25 and August 3, 2017 that included top 50 Alexa pages and some smaller pages, the combined metrics specified in the Adapting Text SC should be feasible in WCAG 2.1 for HTML documents. Spacing is able to adapt without loss of content or functionality across a wide range of sites. In addition recently 9 mega menus were tested and passed the SC.
The Working Group will be going through the implementation process and demonstrating the implementability of all the new SCs. If you know of examples in the wild of text in UI - (e.g. menus, etc) where it would not be possible to meet the SC, please add them to this issue.
We are tagging this issue with the "Implementation Follow-up" label to ensure that it is re-reviewed at that point in our process. In addition we will add the following editor's note:
"Editors Note: The Working Group seeks examples in the wild of text content outside of blocks of text where it would be impossible to meet this SC. The SC's scope may be narrowed based upon implementation testing."
Issue 577: Adapting text: Ensure end users get the results with only changing 4 items in CSS
Capturing my concern as we closed out the call.
In responding to a comment #409 requesting we fix the definition of adapting text, we reworded the SC to remove adapt
"If the technologies being used allow the user agent to change text style properties, the following can be achieved with no loss of essential content or functionality: * the 4 things"
The problem with this wording is that an author could get a pass on this if the only way to achieve the 4 things was to change box properties and a bunch of other CSS tweaks in addition to those 4 things. I propose instead we go back to the previous language which was painfully and carefully crafted, and swap out "adapt" for "change":
"If the technologies being used allow the user agent to change text style properties, then no loss of essential content or functionality occurs by changing all of the following: * the 4 things"
It is only 10 characters longer than the new proposal, and it preserves the word ALL, as well as ensuring the end user would only have to over ride those 4 text properties, and wouldn't be required to write a bunch of other CSS like box padding, margins etc...
Proposed Response
Thank you, David for pointing out that the language proposed at the November 13 meeting would introduce a loophole.
As discussed on the Working Group list between November 13-20, 2017, the SC has been reworded to close that loophole.