search

w3c / wcag

Web Content Accessibility Guidelines
https://w3c.github.io/wcag/guidelines/22/
Other
1.11k stars 252 forks source link

Understanding 1.4.10: "In brief" knows only text and horizontal scrolling (i18n) #3385

Closed JAWS-test closed 7 months ago

JAWS-test commented 1 year ago

In brief:

Objective: Content can be enlarged without requiring horizontal scrolling

... or without vertical scrolling

Author task: Make text reflow within the width of the viewport

alastc commented 1 year ago

I think this is simply due to trying to create a very short and simple sentence.

There is a question around the internationalisation though, looping in @mbgower for his thoughts...

bruce-usab commented 1 year ago

Definitely some tension comes with keeping In Brief short and simple. Maybe:

Objective: Content can be enlarged without requiring horizontal scrolling (for languages written left-to-right).

The "without horizonal scrolling" is the simplified core concept that folks commonly miss from their first reading of the SC text.

mbgower commented 1 year ago

@JAWS-test it's not as simple as saying 'without horizontal or vertical scrolling' because of course that means that you can't scroll at all!

I think it's important to point out that this did just pass a full review by the working group a couple of months ago, where this very topic was debated for some time...

At one point I proposed "sideways" which I think should work in both cases, based on the context of the reader, but few seemed to like that as much as I did.

Given the SC talks about both horizontal AND vertical scrolling, I agree it's a challenge. My brief investigation suggests there are very few languages in the world that are exclusively written vertically, and if we ever had translations of WCAG for those languages, we could simply 'flip' the language. That was the basic reason this got okayed with saying "horizontal". It applies to and seems understandable for people using almost every written language.

If I was going back to this SC now, I would advocate for using "horizontally" in the normative language and address vertical languages (or any alphabet laid out on the vertical plane) in a note. But unfortunately I have not yet mastered overcoming the space-time continuum.

BTW, since I'm looking at the 2.1 In Brief wording in a currrent PR where I've added in the 'why'. I'll point out that there's a less glaring but parallel problem with "width" in the What line, if we ARE going to try to address this.

Bruce has already made the point, but remember this is a brief summary. We spend a LOT of time on this in the Understanding document, and an outcome of brevity tends to be imprecision.

That said, let's revisit "sideways" for use in "in brief". I see it is used once in the Understanding doc, so we have our butts covered. Anyone think this is better in a brief description?

Current

Goal
Content can be enlarged without requiring horizontal scrolling.
What to do
Make text reflow within the width of the viewport.
Why it's important
People who need larger text find it difficult to read long lines of text.
#### Suggested
Goal
Content can be enlarged without requiring sideways scrolling.
What to do
Make text reflow within the viewport.
Why it's important
People who need larger text find it difficult to read long lines of text.
--- I think that solves both problems. Potentially someone could argue "within the viewport" is TOO constraining, but I think we _may_ be over critiquing.
GreggVan commented 1 year ago

Since this says Horiz OR vertical and not Horiz AND vertical — I think the issued does not arise (though that subtlety should be explained in the Understanding doc)

Also "without horizontal was meant for left-right(or right-left) text and vertical was meant for Top/down text.

Clearly we need to do a better job of this in WCAG 3.0. I think for 2.2 (since it is in the can) we should fix it in Understanding.

ALSO the reason for the no-horizontal scrolling is not "people have trouble with long lines" exactly I was told it was actually "People who have to horizontally scroll have difficulty tracking on the line when scrolling and also finding the ’next line’ when they scroll back."

gregg

——————————— Professor, University of Maryland, College Park Founder and Director Emeritus , Trace R&D Center, UMD Co-Founder Raising the Floor. http://raisingthefloor.org The Global Public Inclusive Infrastructure (GPII) http://GPII.net The Morphic project https://morphic.org

On Sep 22, 2023, at 11:47 AM, Mike Gower @.***> wrote:

@JAWS-test https://github.com/JAWS-test it's not as simple as saying 'without horizontal or vertical scrolling' because of course that means that you can't scroll at all!

I think it's important to point out that this did just pass a full review by the working group a couple of months ago, where this very topic was debated for some time...

At one point I proposed "sideways" which I think should work in both cases, based on the context of the reader, but few seemed to like that as much as I did.

Given the SC talks about both horizontal AND vertical scrolling, I agree it's a challenge. My brief investigation suggests there are very few languages in the world that are exclusively written vertically, and if we ever had translations of WCAG for those languages, we could simply 'flip' the language.

If I was going back to this SC now, I would advocate for using "horizontally" in the normative language and address vertical languages (or any alphabet laid out on the vertical plain) in a note. But unfortunately I have not yet mastered overcoming the space-time continuum.

BTW, since I'm looking at the 2.1 In Brief wording in a currrent PR https://github.com/w3c/wcag/pull/3312 where I've added in the 'why'. I'll point out that there's a less glaring but parallel problem with "width" in the What line, if we ARE going to try to address this.

Bruce has already made the point, but remember this is a brief summary. We spend a LOT of time on this in the Understanding document, and an outcome of brevity tends to be imprecision.

That said, let's revisit "sideways" for use in "in brief". I see it is used once in the Understanding doc, so we have our butts covered. Anyone think this is better in a brief description?

Current

Goal Content can be enlarged without requiring horizontal scrolling. What to do Make text reflow within the width of the viewport. Why it's important People who need larger text find it difficult to read long lines of text. Suggested

Goal Content can be enlarged without requiring sideways scrolling. What to do Make text reflow within the viewport. Why it's important People who need larger text find it difficult to read long lines of text. I think that solves both problems. Potentially someone could argue "within the viewport" is TOO constraining, but I think we may be over critiquing.

— Reply to this email directly, view it on GitHub https://github.com/w3c/wcag/issues/3385#issuecomment-1731895593, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACNGDXV5Q46CU4JUMTJ545LX3XMMXANCNFSM6AAAAAA4XMVE7Q. You are receiving this because you are subscribed to this thread.

mbgower commented 1 year ago

@GreggVan and @JAWS-test, neither of you has responded to my suggested change. Please do so.

People who have to horizontally scroll have difficulty tracking on the line when scrolling and also finding the ’next line’ when they scroll back."

That notion seems to me to be fairly captured in the phrase "people have trouble with long lines"

The Understanding document currently says:

Reflow enables tracking. Tracking is following along lines of text, including getting from the end of one line to the beginning of the next line.

We can always build on this existing text. I have now referenced this issue in the Issue created to do updates to Understanding documents based on the "in brief" material.

mbgower commented 1 year ago

Actually, I took another stab at this today, and I think I may have arrived at something that works better. How about:

Goal
Content can be enlarged without affecting line length.
What to do
Make lines of text reflow within the viewport.
Why it's important
People who need bigger text find it difficult if they must scroll to read long lines.
detlevhfischer commented 1 year ago

Content can be enlarged without affecting line length.

@mbgower That's confusing IMO - reflow does exactly that, affect line length? Not semantically perhaps, but visually.

mbgower commented 1 year ago

reflow does exactly that, affect line length

It depends on how you consider it -- whether you're talking about the number of characters or the actual physical length. I get the problem, and believe me, it's a very tough thing to express simply in a few words.

How about "increasing"?

Content can be enlarged without increasing the line length

mbgower commented 1 year ago

I've actually accepted those changes. This is how it nows reads:

Goal
Content can be enlarged without increasing line length.
What to do
Make lines of text reflow within the viewport.
Why it's important
People who need bigger text find it difficult if they must scroll to read long lines.
mbgower commented 7 months ago

@JAWS-test The In Brief text was updated so that it no longer refers to direction. Please see https://www.w3.org/WAI/WCAG22/Understanding/reflow.html If you feel your concern was not addressed by the update, please reopen and add comments.