notes in text-spacing

[shawna-slh]

First note: More direct language focused on the common misunderstanding.

The rest trying to be succinct covering minimum needed in /TR and rest in Understanding.

Rationale: The goal is in the TR/WCAG wording to clearly and succinctly:

• clarify that you don’t have to do this in your content
• fyi, there are other things in other languages/scripts/writing systems

Can everything else can go in the Understanding docs, and needn't complicate TR/WCAG? Do we need to say these in the TR doc?

• might not be sufficient for all languages
• use any locally available guidance for improving readability in the local language or writing system
  If the user chooses to go beyond the metrics specified, any resulting loss of content or functionality is the user's responsibility

If we need to cover those in these notes, I would like to suggest similar copy edits for clarity.

@alastc @aphillips @iadawn

---

Preview | Diff

[aphillips]

Thanks @shawna-slh

See suggestions.

One final note: I would probably combine the last paragraph and my suggested addition into a single note, rather than having three separate green boxes.....

[aphillips]

I'm giving an approving review, although I am nervous that the text is too brief and invites quibbling about many of the issues we've discussed elsewhere. We can do more in the understanding docs later.

[mbgower]

[Apologies for sending my comments to the email thread. Reposting into this PR discussion...]

I have concerns that this note is being added to the technical guidelines content. The note seems fairly non-essential in regard to authors meeting the requirement for text spacing.

I see that it is one of three notes that have been added since the last publication. I’m concerned about the second and third notes appearing in the technical spec for a few reasons.

First, there has been a move to cut down on the notes in the technical spec, which I support philosophically. Namely, the argument is that notes that occur there instead of in the Understanding document have information of sufficient importance that it bears on interpretation of the normative language. Neither of these notes seem to me to reach that threshold.

Second, the notes seem unsupported by language in the Understanding document. This not only makes it difficult for anyone to understand how they may be important enough to be TR notes, but makes it hard to understand exactly what they mean, in regard to meeting or interpreting the SC. On the strength of the wording, I would even question whether they rate being notes in the Understanding document. They seem possilbe to address through some new content in the Understanding document body, say covering localization/internationalization.

Third, the very fact the first content proposed to address these considerations is a technical note suggests they may not have been adequately considered – otherwise, supporting information should be present elsewhere.

These notes must have been debated on a call I missed. Apologies for only flagging these concerns at this point, but I would like some more consideration before publishing. I can see a final sentence in the third note that may also meet a TR threshold (about it being a user’s problem if they make text spacing larger than these settings and it affects the content). That is supported by existing language in the Understanding document, and anecdotally I've seen questions of this nature.

Mike
PS The first note, on the content not having to use the values specified, is already supported by information in the Understanding document. I can see that if the SC was being misinterpreted, this note can make for a more appropriate reading of the normative text, and I support it.

[mbgower]

BTW, I see my post brings about a concern that @aphillips expressed earlier in the conversation :)

I am nervous that the text is too brief and invites quibbling about many of the issues we've discussed elsewhere. We can do more in the understanding docs later.

To me, a change of this nature must have that supporting text now. That should be part of the PR, which will both reduce potential quibbling, and help the guidance find its appropriate wording and level.

[alastc]

Hi @mbgower, I think you missed #3347 and #3351 which were highlighted in a meeting, onlist and then had discussions and itterations on the github threads.

The bottom line is that we needed these to get through the transition to rec. Happy to update (or accept updates) on the understanding doc, but this PR is from Shawn to improve the readability of what's there.

[mbgower]

I think you missed #3347 and #3351 which were highlighted in a meeting, onlist and then had discussions and itterations on the github threads.

Yep, some happened while I was on vacation (or while dealing with a flooded inbox on my return). It seems these were fairly quick responses to objections to 2.2, so that explains some of the haste in their wording and addition. I do find it a little odd that comments about pre-existing SCs are appropriate to the release of 2.2. I assume that comments do not need to be confined only to additive content in the latest release, and one is able to object as part of the CR process to anything written for any release including 2.0 in 2008?

Are the Notes considered normative? If they are not normative, then we should be able to update them, just like any other non-normative text. So further PRs could seek improvements and get them better aligned with other SC usage. If they are normative, we're stuck with this language, barring errata. At a minimum the explanation for why they were added and what the actual author ask is needs to be in the Understanding document, IMO.

Looking at #3338, it seems to primarily seek better context for the existing exception. Is there a reason no additional information from the issue was incorporated into the Understanding document? For example, the two-paragraph wording suggested for the note, along with other text later in the issue, could easily serve as the draft text for an expanded part of the Author responsibility section of the Understanding document, or probably better, a separate sub-section titled something like "Human languages and scripts exception".

It's also possible JIS X 8341-3 discussed in #2680, as well as other standards and specs relevant to this SC should be in the References section.

[mbgower]

Hmm, looks like a separate PR may have already done some of the Understanding changes.
#3347

Sorry, trying to sort out/identify these different PR pieces of the same basic issue.

I think my comments on referencing JIS X 8341-3 is still relevant, and I would like an answer on whether the TR notes are considered normative.

[alastc]

Are the Notes considered normative?

They are informative, but won't change without a republication. The understanding docs need updates, but the notes needed to be finalised for publication so took priority.

[mbgower]

With a bit more context from the other relevant PRs, and a view that this is not something worthy of holding up the spec, I'm okay with this PR getting merged. Thanks