Success Criterion 1.4.12: Text Spacing (Level AA)

[ferBonnin]

From Success Criterion 1.4.12:

In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

• Line height (line spacing) to at least 1.5 times the font size;
• Spacing following paragraphs to at least 2 times the font size;
• Letter spacing (tracking) to at least 0.12 times the font size;
• Word spacing to at least 0.16 times the font size.

Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.

Additional Guidance When Applying Success Criterion 1.4.12 to Non-Web Documents and Software:

This applies directly as written and as described in Intent from Understanding Success Criterion 1.4.12 replacing "In content implemented using markup languages that support" with "For non-web documents or software using markup languages that support"

With these substitutions, it would read:

For non-web documents or software implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

• Line height (line spacing) to at least 1.5 times the font size;
• Spacing following paragraphs to at least 2 times the font size;
• Letter spacing (tracking) to at least 0.12 times the font size;
• Word spacing to at least 0.16 times the font size.

Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.

Note: Markup properties are not always exposed to the user to modify. Software sometimes uses markup languages internally for persistence of the software user interface in ways where the markup is never available to the user. In such cases, the user cannot modify the style properties.

Examples of markup that is used internally for persistence of the software user interface and is never exposed to the user to modify include but are not limited to: XAML and XUL.

// Additional notes for further conversation:
Now, as 1.4.12 is not about providing the method for text spacing but rather, if the user can apply text spacing properties then there should be no loss of functionality or content as @mraccess77 mentioned below, this note could be not necessary because to start with, I don't believe there is a way for the user to apply these styling properties in markup used internally

edited after WCAG2ICT TF conversation.
4.1.1 Parsing, from the previous WCAG2ICT, also refers to markup used internally (although in that case its for markup not exposed to assistive technologies)

[pday1]

I think this reads well.
I assume that software or systems with closed functionality would fail the "non-web documents or software that use markup languages, in such a way that the markup is exposed to the user, and support the following text style properties" clause - and so would be excluded from this. Is that correct?

[ferBonnin]

I assume that software or systems with closed functionality would fail the "non-web documents or software that use markup languages, in such a way that the markup is exposed to the user, and support the following text style properties" clause - and so would be excluded from this. Is that correct?
@pday1 yes, that was my intent with that text proposal, to cover those cases where there is no way for a user to actually modify the markup

[mraccess77]

SC 1.4.12 doesn't require that the text spacing can be changed - only that loss of content or functionality does not occur when set.

[samogami]

Note: Markup is not always never exposed to the user to modify. Software sometimes uses markup languages internally for persistence of the software user interface in ways where the markup is never available to the user. In such cases, the user cannot modify the style properties.

The note part of the SC "not always never" is confusing. Change to: "Markup is not always exposed to the user to modify."

[loicmn]

I think that the note (and example) does not cover all the possibilities. After carefully reading the intent of 1.4.12 and thinking about its applicability to non-web documents and non-web software, I see these possibilities:

1. Markup language is used, and the markup language is exposed to the user to modify. Then the SC applies.
2. Markup language is used, the markup language is not exposed to the user to modify, but there is a mechanism for the user to modify text style properties (i.e., text presentation settings). Then the SC applies.
3. Markup language is used, the markup language is not exposed to the user to modify, and there are no other mechanisms for the user to modify the text style properties. Then the SC does not apply.

In my opinion, the note as written covers cases 1 and 3, but not case 2. Thus, I suggest a modification of the note and example (the change to the example is minor, by saying "normally not exposed" instead of "never exposed"):

Note: Markup is not always exposed to the user to modify. Software sometimes uses markup languages internally for persistence of the software user interface in ways where the markup is never available to the user. In such cases, the only way the user could modify the text style properties is through a mechanism provided by the software, such as a settings dialog box. In that case, 1.4.12 would still apply. However, if the markup is not exposed to the user and there is no other mechanism for the user to modify the text style properties, then the SC would not apply.

Examples of markup that is used internally for persistence of the software user interface and is normally not exposed to the user to modify include but are not limited to: XAML and XUL.

[mitchellevan]

1. Markup language is used, and the markup language is exposed to the user to modify. Then the SC applies.
2. Markup language is used, the markup language is not exposed to the user to modify, but there is a mechanism for the user to modify text style properties (i.e., text presentation settings). Then the SC applies.

I agree. This is good for users, consistent with the intent, and no more or less burdensome on developers.

A different word substitution would help convey both 1 and 2. Proposed text:

This applies directly as written... replacing "In content implemented using markup languages that support" with "For non-web documents or software that do not prevent users from setting"

With this substitution, it would read:

For non-web documents or software that do not prevent users from setting the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property: ...

(end of proposed text)

A potential problem: if we don't explicitly mention "markup languages," it raises the possibility of some future non-web non-markup-language technology falling under 1.4.12 that otherwise would have been exempted. This would also be good for users and I hope not burdensome for developers — after all, this future technology by definition allows users to set text spacing styles. But if we can't take that risk, is there a way to say the following in plain-enough language?

For non-web documents or software using markup languages that support the following text style properties, where the technologies being used do not prevent users from setting the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property: ...

Also, I suggest the following edit for clarity.

Note: Markup is Markup properties are not always exposed to the user to modify.

[ferBonnin]

@loicmn this section can be misunderstood as requiring the software to provide such mechanism:

In such cases, the only way the user could modify the text style properties is through a mechanism provided by the software, such as a settings dialog box.

I think the S.C. doesn't require the content to implement its own mechanism to do this nor is a failure of the content if the user agent or platform doesn't provide a way to do this.

[bruce-usab]

edited after WCAG2ICT TF conversation.

4.1.1 Parsing, from the previous WCAG2ICT, also refers to markup used internally (although in that case its for markup not exposed to assistive technologies)

This distinction between "markup used internally" and "markup exposed to assistive technology" has a lot of utility in my opinion. As time allows, I recommend that we revisit previous WCAG2ICT guidance referencing markup language to consider applying a similar caveat for non-web software and documents.

[maryjom]

Based on the 19 November Task Force discussion and survey results:

I updated the draft above to incorporate the suggestion from @mitchellevan

Note: Markup is Markup properties are not always exposed to the user to modify.

@mitchellevan The Task Force is limited on how much we can make modifications to normative text. Typically ONLY to address web-based technology language with non-web technology based language.

@loicmn will make adjustments to Gregg's suggestion made in the survey to modify the note. Gregg's suggestion was:

This applies as written for Markup Languages that are exposed to user manipulation via AT, or built-in features of the software or platform.

[mitchellevan]

The Task Force is limited on how much we can make modifications to normative text.

Understood, thanks for explaining.

@loicmn will make adjustments to Gregg's suggestion made in the survey to modify the note. Gregg's suggestion was:

This applies as written for Markup Languages that are exposed to user manipulation via AT, or built-in features of the software or platform.

(Emphasis mine).

+1. This adds the clarity I was looking for.

[loicmn]

As per my assignment in the last TF meeting, I propose the following, based on the idea that it is enough to point to "markup languages that are exposed to user manipulation", as the way the users manipulate it is not relevant for the SC.

First, changes in the "substitution" text for non-web:

This applies directly as written and as described in Intent from Understanding Success Criterion 1.4.12 replacing "In content implemented using markup languages that support" with "For non-web documents or software using markup languages that are exposed to user manipulation and that support"

Second, with this change, the "substituted SC" would be:

For non-web documents or software using markup languages that are exposed to user manipulation and that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property: [...]

Third, add a new note 1

Note 1: Markup languages can be exposed to user manipulation in several ways. One possibility would be to enable direct access to the file containing the markup language. Another possibility would be for non-web software to have a built-in mechanism enabling the users to modify the properties stored in the markup language.

Fourth, renumbering the current note into note 2, with a minor change: put back "languages" instead of "properties":

Note 2: Markup languages are not always exposed to the user to modify. Software sometimes uses markup languages internally for persistence of the software user interface in ways where the markup is never available to the user. In such cases, the user cannot modify the style properties.

Fifth, a slight modification to the example, replacing "never exposed" with "normally not exposed":

Examples of markup that is used internally for persistence of the software user interface and is normally not exposed to the user to modify include but are not limited to: XAML and XUL.

[maryjom]

For Loïc's first and 2nd proposed change:
There is precedence where WCAG2ICT did substitute

“In content implemented using markup languages” with “For non-web documents or software that use markup languages, in such a way that the markup is separately exposed and available to assistive technologies and accessibility features of software or to a user-selectable user agent”.

So this could be a good substitution, though I would add in "content implemented" into the replacement phrase because it's about what is appearing in the user interface. Then it would read "For non-web documents or software content implemented using markup languages that are exposed to user manipulation and that support"

Note 1 is good, but I am a little concerned about this implying that software must expose this to the user to implement. That is not what this requirement is about. It's about the content author's requirements.

The last two changes seem ok to me.

[maryjom]

Part of this conversation should be modification/interpretation needed for the new definition of "style properties". Suggest the following WCAG2ICT interpretation and definition:

From the WCAG 2.2 definition for style property:

style property
property whose value determines 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)

Additional Guidance When Applying the Definition of “style property” to Non-Web Documents and Software

 
This applies directly as written and as described in the WCAG 2.2 glossary, replacing “user agent(s)” with “user agent(s) or other software”, “web content” with “content implementation”, “author style sheets” with “content templates”, and “user agent interface settings, user style sheets” with “user agent, application, or platform software interface settings”.
 
With these substitutions, it would read:

style property

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 or other software]

Style properties can have several origins:

• [User agent or other software] default styles: The default style property values applied in the absence of any author or user styles. Some [content implementation] 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, [content templates]);
• User styles: Style property values that are set by the user (e.g. via [user agent, application, or platform software interface settings])

[loicmn]

I agree with @maryjom proposal for the success criterion (based on 2013 WCAG2ICT wording. And I also agree with the proposed definition for the new term "style property" for WCAG2ICT.

As for note 1, my intention was not to imply that software must offer access to markup language. The purpose of the note is purely descriptive, explaining different ways of exposing markup language.

So I propose a new wording for note 1, based on the new word substitution proposed by @maryjom:

Note 1: There are several mechanisms that enable exposing markup languages to user manipulation. One possibility would be to enable direct access to the file containing the markup language. Another possibility would be to have a built-in mechanism enabling the users to modify the properties stored in the markup language.

[mraccess77]

For internal markup languages it may be difficult or impossible for the tester to know that a markup language was used. So I agree with the last comment that this SC only applies when the markup language style can be changed by the user and NOT when other style properties exist. The understanding document says this

If the markup-based technologies being used are capable of overriding text to the Success Criterion's metrics, then this SC is applicable
https://www.w3.org/WAI/WCAG21/Understanding/text-spacing

[ferBonnin]

Proposing an update taking in consideration comments above as well as WCAG2ICT meeting discussion

Proposed changes

From Success Criterion 1.4.12:

In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

• Line height (line spacing) to at least 1.5 times the font size;
• Spacing following paragraphs to at least 2 times the font size;
• Letter spacing (tracking) to at least 0.12 times the font size;
• Word spacing to at least 0.16 times the font size.

Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.

Additional Guidance When Applying Success Criterion 1.4.12 to Non-Web Documents and Software:

This applies directly as written and as described in Intent from Understanding Success Criterion 1.4.12 replacing "In content implemented using markup languages" with "For non-web documents or software content implemented using markup languages" and adding: "in such a way that the markup is exposed and available to user modification"

With these substitutions, it would read:

For non-web documents or software content implemented using markup languages, in such a way that the markup is exposed and available to user modification, and that support the following text [style properties] (https://www.w3.org/WAI/WCAG21/Understanding/text-spacing#dfn-style-property):

• Line height (line spacing) to at least 1.5 times the font size;
• Spacing following paragraphs to at least 2 times the font size;
• Letter spacing (tracking) to at least 0.12 times the font size;
• Word spacing to at least 0.16 times the font size.
  no loss of content or functionality occurs by setting all of the following and by changing no other style property.

Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.

Notes:

• Note 1: There are several mechanisms that enable exposing markup languages to user modification: for example, enabling direct access to the file containing the markup language or having a built-in mechanism enabling the users to modify the properties stored in the markup language. However, this S.C. does not require that content implements its own mechanisms to allow users to change the line height and spacing metrics.
• Note 2: Markup is not always exposed to the user to modify. Software sometimes uses markup languages internally for persistence of the software user interface in ways where the markup is not available to the user. In such cases, the user cannot modify the style properties. Examples of markup that is used internally for persistence of the software user interface and is normally not exposed to the user to modify include but are not limited to: XAML and XUL.

Summarized list of changes:

• Added clarification on note 1, to represent that the S.C. doesn’t require that the markup is exposed for user modification. Kept the examples as they can help understand cases on how the markup could be exposed for users to modify.
• Integrated suggested changes from the WCAG2ICT meeting and in this PR
• Added back implemented in the S.C. wording
• Ensured we consistently use modification instead of manipulation

[mitchellevan]

Here is an alternate proposal, focusing on modification of just the text spacing properties, not requiring modification of the markup itself.

Proposed changes

From Success Criterion 1.4.12:

In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

• Line height (line spacing) to at least 1.5 times the font size;
• Spacing following paragraphs to at least 2 times the font size;
• Letter spacing (tracking) to at least 0.12 times the font size;
• Word spacing to at least 0.16 times the font size.

Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.

Additional Guidance When Applying Success Criterion 1.4.12 to Non-Web Documents and Software:

This applies directly as written and as described in Intent from Understanding Success Criterion 1.4.12 replacing "In content implemented using markup languages that support the following text style properties" with "In non-web document or software content, implemented using markup languages in a way that allows users to modify the following text style properties"

With these substitutions, it would read:

In non-web document or software content, implemented using markup languages in a way that allows user to modify the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

• Line height (line spacing) to at least 1.5 times the font size;
• Spacing following paragraphs to at least 2 times the font size;
• Letter spacing (tracking) to at least 0.12 times the font size;
• Word spacing to at least 0.16 times the font size.

Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.

Notes:

• Note 1: There are several mechanisms that allow users to modify text spacing properties: for example, enabling direct access to the file containing the markup language or having a built-in mechanism enabling the users to modify the spacing properties of the markup language. However, this SC does not require that content implements its own mechanisms to allow users to change text spacing properties.
• Note 2: Markup is not always exposed to the user to modify. Software sometimes uses markup languages internally for persistence of the software user interface in ways where the markup is not available to the user. In such cases, the user cannot modify the style properties. Examples of markup that is used internally for persistence of the software user interface and is normally not exposed to the user to modify include but are not limited to: XAML and XUL.

[ferBonnin]

Here is an alternate proposal, focusing on modification of just the text spacing properties, not requiring modification of the markup itself.

@mitchellevan thanks for that suggestion, I like the changes on Note 1. I would still suggest keeping Note 2 as it adds additional relevant information

[ferBonnin]

re-adding the full proposed text in a single comment so its easier to read:

Proposing an update taking in consideration comments above as well as WCAG2ICT meeting discussion

Proposed changes

From Success Criterion 1.4.12:

In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

• Line height (line spacing) to at least 1.5 times the font size;
• Spacing following paragraphs to at least 2 times the font size;
• Letter spacing (tracking) to at least 0.12 times the font size;
• Word spacing to at least 0.16 times the font size.

Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.

Guidance When Applying Success Criterion 1.4.12 to Non-Web Documents and Software:

This applies directly as written and as described in Intent from Understanding Success Criterion 1.4.12 replacing "In content implemented using markup languages" with "For non-web documents or software content implemented using markup languages" and adding: "in such a way that the markup is exposed and available to user modification".

With these substitutions, it would read:

[For non-web documents or software] content implemented using markup languages, [in such a way that the markup is exposed and available to user modification,] and that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

• Line height (line spacing) to at least 1.5 times the font size;
• Spacing following paragraphs to at least 2 times the font size;
• Letter spacing (tracking) to at least 0.12 times the font size;
• Word spacing to at least 0.16 times the font size.

Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.

Notes:

• Note 1: There are several mechanisms that allow users to modify text spacing properties: for example, enabling direct access to the file containing the language or having a built-in mechanism enabling the users to modify the properties stored in the markup. However, this S.C. does not require that content implement its own mechanisms to allow users to change the text spacing properties.
• Note 2: Markup is not always exposed to the user to modify. Software sometimes uses markup languages internally for persistence of the software user interface in ways where the markup is not available to the user. In such cases, the user cannot modify the style properties. Examples of markup that is used internally for persistence of the software user interface and is normally not exposed to the user to modify include but are not limited to: XAML and XUL.

Summarized list of changes:

• Added clarification on note 1, to represent that the S.C. doesn’t require that the markup is exposed for user modification. Kept the examples as they can help understand cases on how the markup could be exposed for users to modify.
• Integrated suggested changes from the WCAG2ICT meeting and in this PR
• Added back implemented in the S.C. wording
• Ensured we consistently use modification instead of manipulation
• integrated @mitchellevan comments on Note 1 (and I propose keeping Note 2)

[mraccess77]

I'm unsure about ""in such a way that the markup is exposed and available to user modification". For web, the user isn't modifying the markup but style properties associated with the markup - so I'm not sure how it should be worded - the wording above could be interpreted as they user modifying the markup itself rather than modifying the styles associated with the markup.

[maryjom]

@ferBonnin I have opened a new survey of 1.4.12 due 9 March.

[maryjom]

I did a very minor edit to @ferBonnin's comment with the updated proposal to remove a space so the link appears properly.

[maryjom]

Was it intentional that the phrase, "no loss of content or functionality occurs by setting all of the following and by changing no other style property." is appearing after the list of properties? Or should it be added to the text before the list of bullets?

[ferBonnin]

Was it intentional that the phrase, "no loss of content or functionality occurs by setting all of the following and by changing no other style property." is appearing after the list of properties? Or should it be added to the text before the list of bullets?

thank you for catching that @maryjom, to maintain the same format as the S.C. text, changed it to be added to the text before the list of bullets

[maryjom]

Another tiny edit to remove "Additional" from the heading. The editor's removed this to reduce heading length and the SC draft template just got updated to reflect that change.

[maryjom]

I've taken in what others have commented on, and tried to make adjustments so it isn't misread. I completely simplified Note 1, as I think it went into some tangential information about available methods to modify text properties. This SC is focused on "IF those properties are modified", then you shouldn't lose information.

In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

• Line height (line spacing) to at least 1.5 times the font size;
• Spacing following paragraphs to at least 2 times the font size;
• Letter spacing (tracking) to at least 0.12 times the font size;
• Word spacing to at least 0.16 times the font size.

Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.

Guidance When Applying Success Criterion 1.4.12 to Non-Web Documents and Software:

This applies directly as written and as described in Intent from Understanding Success Criterion 1.4.12 replacing "content" with "non-web document or software" and adding: "where support is available to expose text style properties to user manipulation".

With these substitutions, it would read:

In [non-web document or software] content implemented using markup languages that support the following text style properties,[and there is markup language support that exposes these text style properties to user manipulation,] no loss of content or functionality occurs by setting all of the following and by changing no other style property:

• Line height (line spacing) to at least 1.5 times the font size;
• Spacing following paragraphs to at least 2 times the font size;
• Letter spacing (tracking) to at least 0.12 times the font size;
• Word spacing to at least 0.16 times the font size.

Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.

Note 1: This Success Criterion does not require non-web documents or software to implement mechanisms that allow users to change text spacing properties.
Note 2: Markup, or the user interface properties it represents, is not always exposed to the user to modify. Software sometimes uses markup languages internally for persistence of the software user interface and, if text style properties are supported, they still may not be made available to the user for modification. Examples of markup that is used internally for persistence of the software user interface and is normally not exposed to the user to modify include but are not limited to: XAML and XUL.

[ferBonnin]

Adding text agreed in TF meeting (Note 2 will require additional edits per comments):

Proposed changes

From Success Criterion 1.4.12:

In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

• Line height (line spacing) to at least 1.5 times the font size;
• Spacing following paragraphs to at least 2 times the font size;
• Letter spacing (tracking) to at least 0.12 times the font size;
• Word spacing to at least 0.16 times the font size.

Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.

Guidance When Applying Success Criterion 1.4.12 to Non-Web Documents and Software:

This applies directly as written and as described in Intent from Understanding Success Criterion 1.4.12 replacing "In content implemented using markup languages" with "For non-web documents or software content implemented using markup languages" and replacing "that support " with "in a way that supports modification of".

With these substitutions, it would read:

[For non-web documents or software] content implemented using markup languages [in a way that supports modification of] the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:

• Line height (line spacing) to at least 1.5 times the font size;
• Spacing following paragraphs to at least 2 times the font size;
• Letter spacing (tracking) to at least 0.12 times the font size;
• Word spacing to at least 0.16 times the font size.

Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.

Notes:

• Note 1: There are several mechanisms that allow users to modify text spacing properties: for example, enabling direct access to the file containing the language or having a built-in mechanism enabling the users to modify the properties stored in the markup. However, this S.C. does not require that content implement its own mechanisms to allow users to change the text spacing properties.
• Note 2: TBD rewrite to address concerns. @mitchellevan will propose text.

[mitchellevan]

Here's a new proposal for the two Notes.

Note 1: "Content implemented using markup languages" includes parts of software that use markup internally to define a user interface. Examples of markup languages that are used internally to define a software user interface include but are not limited to: HTML (e.g., in Electron apps or iOS app web views), XAML, XML (e.g., in Android app layouts), and XUL.

Note 2: There are several mechanisms that allow users to modify text spacing properties of content implemented in markup languages. For example, an eBook technology may have an available user agent that allows users to override document text styles, or a software application may provide a "user style sheet" facility to modify the appearance of the software's own user interface. This S.C. does not require that documents and software implement their own mechanisms to allow users to set text spacing; however, when such a mechanism is available, the S.C. requires that content respond appropriately to it.

While addressing the concerns we discussed today, I made these additional changes:

• I switched the order of notes 1 and 2 so they can build on each other.
• I omitted "persistence of" the software user interface, which doesn't seem relevant to this SC.
• I added modern examples of markup languages used for software user interfaces.
• I removed the "direct access to the file" example. (I was unclear about what kind of file that might be. I'm happy to add it back in if somebody wants to speak up for it.)
• I added a document example.

[mraccess77]

Plus 1 to the additions regarding support for controlling those styles in the user agent (when provided) being reflected in the content.

[maryjom]

@mitchellevan I like these proposals. Note that "SC" will get spelled out as "Success Criterion" in all instances whenever the text gets implemented. The shorthand is fine for our discussions.

[maryjom]

New survey.

[bruce-usab]

+1 but can we think of another example besides "Electron apps". Maybe just me, but I had to re-read a few times before figuring out that Electron is a proper noun and not a typo for electronic. Android apps?

[maryjom]

This content was approved by the AG WG on 11 April. Closing.