Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

notes in text-spacing #3437

Merged
merged 4 commits into from
Oct 5, 2023
Merged

notes in text-spacing #3437

merged 4 commits into from
Oct 5, 2023

Conversation

shawna-slh
Copy link
Contributor

@shawna-slh shawna-slh commented Sep 29, 2023

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

First paragraph: more direct language focused on the common misunderstanding.

The rest trying to be succinct covering minimum needed in /TR and rest in Understanding. rationale: https://docs.google.com/document/d/1BoPr_AXLoSTAvcm6OOGVm-2FmbIKC7rKTifhnxucQ6Q/edit
@shawna-slh shawna-slh requested review from iadawn and removed request for iadawn September 29, 2023 14:54
Copy link
Contributor

@aphillips aphillips left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

guidelines/sc/21/text-spacing.html Outdated Show resolved Hide resolved
guidelines/sc/21/text-spacing.html Show resolved Hide resolved
Copy link
Contributor

@aphillips aphillips left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

I don't feel there is a need for this phrase to be particularly called out since in isolaiton it doesn't quite communicate anything meaningful
@mbgower
Copy link
Contributor

mbgower commented Oct 4, 2023

[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
Copy link
Contributor

mbgower commented Oct 4, 2023

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
Copy link
Contributor

alastc commented Oct 4, 2023

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
Copy link
Contributor

mbgower commented Oct 4, 2023

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
Copy link
Contributor

mbgower commented Oct 4, 2023

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
Copy link
Contributor

alastc commented Oct 4, 2023 via email

@mbgower
Copy link
Contributor

mbgower commented Oct 4, 2023

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

@iadawn iadawn merged commit c4bfd3a into main Oct 5, 2023
1 check passed
@fstrr fstrr deleted the shawna-slh-patch-3 branch May 23, 2024 22:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants