Technique: Reflow for long URLs

[alastc]

Where a URL is shown on the page (not just in an href), it can create horizontal scrolling at higher zooms or smaller viewports.

This is a technique from @allanj-uaag, I just ported it over to get reviews & updates.

View the rendered version of the technique, and the example.

[detlevhfischer]

I was not aware that the space character would ever occur in a URL - or is it the reformatting with %20 that is addressed in listing space as a break point? (% also occurs in trhe list of default line break points so space may be dropped then?)

overflow-break: break-word: Allows words to be broken and wrapped between letters.

should probably read "...and wrapped between words. "

they do not support these declarations with "a" selector

I do not understand what with "a" selector means - does it mean specifc class selectors like .wrapped ?
Could be clearer.

I think the double test procedure is confusing - I am also not quite sure what a "Responsive Design Mode feature" actually refers to. Any browser that understands breakpoints?

If two different test procedures are indeed necessary, it should be clear what scenario they apply to, and be mutually exclusive (so if you pick A, B does not apply, and vice versa). Tey should also have each have a separate set of expected results.

[allanj-uaag]

Thanks for comments

On Wed, Sep 26, 2018 at 1:39 AM Detlev Fischer ***@***.***> wrote: I was not aware that the space charactr would ever occur in a URL - or is it the reformatting with %20 that is addressed in listing space as a break point? (% also occurs in trhe list of default line break points so space may be dropped then?)

browsers encode space character as %20 before sending to server. based on my testing, no browser breaks at the %. I added some %20 on the example page.

overflow-break: break-word: Allows words to be broken and wrapped between letters. should probably read "...and wrapped between *words*. "

It is between letters. Perhaps, should change to be 'within' words as that's how they state it in the definition The *overflow-wrap* CSS <https://developer.mozilla.org/en-US/docs/Web/CSS> property specifies whether or not the browser should insert line breaks *within* words to prevent text from overflowing its content box. ( https://developer.mozilla.org/en-US/docs/Web/CSS/overflow-wrap)

they do not support these declarations with "a" selector I do not understand what with "a" selector means - does it mean specifc class selectors like .wrapped ? Could be clearer. thanks.

the "a" selector is in CSS a {word-wrap: break-word;} I removed the class (.wrapped) and replaced it with "a" as in line above. and changed the wording so (hopefully) it makes more sense

I think the double test procedure is confusing - I am also not quite sure what a "Responsive Design Mode feature" actually refers to. Any browser that understands breakpoints?

Responsive design mode is found in the Inspect tool in most browsers and allows you to view your content in a variety of mobile device simulators. I included information in that section on how to activate the mode.

If two different test procedures are indeed necessary, it should be clear what scenario they apply to, and be mutually exclusive (so if you pick A, B does not apply, and vice versa). Tey should also have each have a separate set of expected results.

removed Responsive Design mode, as they are different ways of doing the same test and may confuse people. updated version https://rawgit.com/allanj-uaag/wcag21/tech-reflow/tech-reflow-url.html updated example https://rawgit.com/allanj-uaag/wcag21/example-reflow-url/example-reflow-url.html

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#486 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AG_WL-qIPbwqznAqFCojTDhkpQ1TJqYxks5ueyEfgaJpZM4W5oPL> .

-- Jim Allan, Accessibility Coordinator Texas School for the Blind and Visually Impaired 1100 W. 45th St., Austin, Texas 78756 voice 512.206.9315 fax: 512.206.9452 http://www.tsbvi.edu/ "We shape our tools and thereafter our tools shape us." McLuhan, 1964

[alastc]

Hi Jim,

@allanj-uaag are you able to work from the W3C branch here? Sorry, I ported it over to here thinking you could work from that without saying so or checking! Is that a problem?

On a couple of points:

I was not aware that the space character would ever occur in a URL - or is it the reformatting with %20 that is addressed in listing space as a break point?

We need to be careful to say when it is content on the page compared to the attribute, as these two would probably work differently:

<a href="http://examples.com/the%20page.html">http://examples.com/the%20page.html</a>
vs
<a href="http://examples.com/the%20page.html">http://examples.com/the page.html</a>

We should probably make that clear in the description, e.g:

Long sets of characters without a space, such as URLs shown as content, can break reflow when the page is zoomed.

The technique would work for longs bits of text that aren't URLs, although I can't think of anything off hand!

I'm a bit confused by "Note: IE and Edge only support this declaration when used with the following declaration.", does that mean the @media declarations?

Also, if the top code-snippet (for overflow-wrap) is the non-IE version, can we it be consistent and include a comment above to that effect?

Also, for the test procedure I think we should align with the previous reflow ones (e.g. C31), so:

<h3>Procedure</h3>

<p>For strings of text that are wider than 320px:</p>

<ul>
  <li>Display the web page in a user agent capable of 400% zoom and set the viewport dimensions (in CSS pixels) to 1280 wide and 1024 high.</li>
  <li>Zoom in by 400%.</li>
  <li>For content read horizontally, check that all content and functionality is available without horizontal scrolling.</li>
  <li>For content read vertically, check that all content and functionality is available without vertical scrolling.</li>
</ul>

<p>If the browser is not capable of zooming to 400%, you can reduce the width of the browser proportionally. For example, at 300% zoom the viewport should be sized to 960px wide.</p>

<h3>Expected Results</h3>

<p>#3 and #4 are true.</p>

Sorry about the bad-wrapping here, but hopefully that is cut & pastable.

[allanj-uaag]

yes, I can edit from here. More comments below.

On Wed, Sep 26, 2018 at 6:07 PM Alastair Campbell ***@***.***> wrote: Hi Jim, @allanj-uaag <https://github.com/allanj-uaag> are you able to work from the W3C branch here? Sorry, I ported it over to here thinking you could work from that without saying so or checking! Is that a problem? On a couple of points: I was not aware that the space character would ever occur in a URL - or is it the reformatting with %20 that is addressed in listing space as a break point? We need to be careful to say when it is content on the page compared to the attribute, as these two would probably work differently: <a href="http://examples.com/the%20page.html"> http://examples.com/the%20page.html</a> vs <a href="http://examples.com/the%20page.html">http://examples.com/the page.html</a>

In my testing, <a href="http://www.scivis.org/the new page.html"> http://www.scivis.org/the new page.html</a> works fine. the spaces in the href are converted to %20 when transmitted to the server. and <a href="http://www.scivis.org/the%20otherpage%20page.html"> http://www.scivis.org/the new page.html</a>

We should probably make that clear in the description, e.g: Long sets of characters without a space, such as URLs shown as content, can break reflow when the page is zoomed. The technique would work for longs bits of text that aren't URLs, although I can't think of anything off hand!

there are some really long words - supercalafragilisticexpialidocious

I'm a bit confused by "Note: IE and Edge only support this declaration when used with the following declaration.", does that mean the @media declarations?

ah, I see the confusion. I removed all of the @media and @support.They were in place for browser sniffing so the example would work with other browsers. The are not relevant to the technique. IE and Edge only work when using the wildcard * selector as in * {word-wrap: break-word;} any other selector or class fails, e.g. a {word-wrap: break-word;} fails .wrapped {word-wrap: break-word;} fails. the @media and @supports are to sniff out IE and Edge

Also, if the top code-snippet (for overflow-wrap) is the non-IE version, can we it be consistent and include a comment above to that effect? we could make 2 statements. One for Microsoft browsers and one for all

others, or just use * { word-wrap: break-word; /* for IE & Edge */ overflow-wrap: break-word; /* for non-MS browsers */ } thoughts? the above would cover any especially long text including URLs (tho they are the main culprit). Also, for the test procedure I think we should align with the previous

reflow ones (e.g. C31 <https://rawgit.com/w3c/wcag/master/techniques/css/C31.html>), so: <h3>Procedure</h3> <p>For strings of text that are wider than 320px:</p> <ul> <li>Display the web page in a user agent capable of 400% zoom and set the viewport dimensions (in CSS pixels) to 1280 wide and 1024 high.</li> <li>Zoom in by 400%.</li> <li>For content read horizontally, check that all content and functionality is available without horizontal scrolling.</li> <li>For content read vertically, check that all content and functionality is available without vertical scrolling.</li> </ul> <p>If the browser is not capable of zooming to 400%, you can reduce the width of the browser proportionally. For example, at 300% zoom the viewport should be sized to 960px wide.</p> <h3>Expected Results</h3> <p>#3 and #4 are true.</p> Sorry about the bad-wrapping here, but hopefully that is cut & pastable.

done

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#486 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AG_WLzm40CItc8_b3taZYH0hhqOwmAeyks5ufAi6gaJpZM4W5oPL> .

-- Jim Allan, Accessibility Coordinator Texas School for the Blind and Visually Impaired 1100 W. 45th St., Austin, Texas 78756 voice 512.206.9315 fax: 512.206.9452 http://www.tsbvi.edu/ "We shape our tools and thereafter our tools shape us." McLuhan, 1964

[KerstinProbiesch]

@ AGWG

I appreciate such a technique much, cause it is reality that long URL (URI?) are used as link texts. There is one aspect which I feel should be adressed or revised. In G91 (Providing link text that describe the purpose of a link) is written "The URI of the destination is generally not sufficiently descriptive.". Of course both are "just" sufficient techniques and relate to different SC and so on, but I feel it is confusing when in one technique is written that "The URI of the destination is generally not sufficiently descriptive" and then having a technique which explains how to do reflow for something which is "generally not sufficiently descriptive". Or?

[KerstinProbiesch]

In addition - but probably should be a separate github-issue?! I think that "The URI of the destination is generally not sufficiently descriptive" in G91 should be revised or need an additional explanation. It sounds a bit that it is probably a failure but is written in a sufficient technique which is a bit confusing.

[alastc]

Hi @KerstinP,

I can see scenarios where you could have a link with good link text, and have the URL visible as well, or some other large chunk of text, so I think both are valid.

But we should make it clear that these URLs could also fail another SC, so I suggest adding something like this to the end of the description:

Success Criterion 2.4.4: Link Purpose (In Context) requires meaningful link text, and a URL is not generally considered a meaningful link text. However, there are instances where a URL or other long string of text could be used, and this technique is then needed to meet Success Criterion 1.4.10: Reflow.

[mraccess77]

@alastc wrote Success Criterion 2.4.4: Link Purpose (In Context) requires meaningful link text, and a URL is not generally considered a meaningful link text.

But SC 2.4.4 also says "except where the purpose of the link would be ambiguous to users in general. " a url is likely ambiguous to all users and therefore passes. I agree there is a user issue but there was an exception written into the SC on purpose for things like this.

[alastc]

a url is likely ambiguous to all users and therefore passes.

I can see the logic, but my assumption would have been different. Is it mentioned anywhere? I can't see it in the understanding doc or G91, or other techniques that I can find.

It's a bit of a tangent, but I'd assumed that a URL (e.g. www.example.com/page1.html) would be easier for people to scan visually, more negatively impacting people using screenreaders or with cognitive impairments.

However, that's an assumption on my part and I guess it does make sense that if the URL isn't 'sufficiently descriptive', it is therefore ambiguous.

[awkawk]

I hadn't really thought about long non-breaking URI as pertaining to this SC. I definitely do not think that the long URI fail 2.4.4, as @mraccess77 indicates.

We should definitely get clarity on whether long URI not wrapping will trigger a failure of the Reflow SC.

[alastc]

Jim's example page shows that clearly, if you zoom / resize down to 320px, the page reflows but the long URLs create horizontal scrolling.
There's a toggle in the page to activate the CSS that wraps the text, showing the technique. Quite neat!

The 2.4.4 thing is a tangent, which I think has been closed off now, although if someone wants to continue it should be a separate issue.

[awkawk]

I'm not disputing that the long URI's do what is demonstrated, just that we need to be clear if the WG thinks that it is a failure of the Reflow SC.

Also, we need the working example for a sufficient technique to demonstrate the technique rather than demonstrate the failure. Or am I missing something because I am using Safari?

[alastc]

If you use the toggle, the URLs wrap and it doesn't horizontally scroll.

BUT, you do need to have zoomed in or resized to around 320px, as per the SC. Perhaps it would be clearer in a fixed width container?

Unless you consider that URLs fall into the 2d exception of reflow (which would take some talking!), it seems like a clear fail/pass situation, but obviously does need to go to the group.

[KerstinProbiesch]

Hi @alastc , all

as written above I would think that clarification on the quoted statement in G91 is needed. Cause I think a note for the Reflow-SC will depend on wether a long URI as linktext is really generally not sufficient or - as @mraccess77 indicates - ambigous to users.

In case long URI as link texts are "in generally not sufficient", I would think that a failure should be written and that a note in the Reflow SC should adress this new failure.

In case long URI as link texts are ambigous for users in general, the statement in G91 should be deleted.

Success Criterion 2.4.4: Link Purpose (In Context) requires meaningful link text, and a URL is not generally considered a meaningful link text. However, there are instances where a URL or other long string of text could be used, and this technique is then needed to meet Success Criterion 1.4.10: Reflow.

I would think that the wording needs some work. Because of "meaningful link text" it sounds more as a note for 2.4.9 than a note for 2.4.4.

---

Beside what @mraccess77 has written above one other aspect:

In case a long URI as link text is not sufficient in general what to do with content which is also made for print. I'm thinking about footnotes in PDF documents like annual reports and so on, where it is not unusual having URI. Would that not mean that two versions are needed, one for print with URI and one for online, cause the version with URI as link texts would not pass?!

[alastc]

Hi @KerstinP,

I think there's a misunderstanding (which I shared): because the URL is ambiguous (= not sufficient to provide meaning) that means it fits into the exception of 2.4.4, so it is not a failure.

Therefore this technique is not related to 2.4.4, only Reflow.

If you'd like to argue that a URL is more ambiguous to some people than others, which then impacts a few techniques, please open a new issue.

[alastc]

Updated based on the call, mainly to simplify the example. The example is now a fixed width 320px container, so the URLs obviously go out of the container without the toggle applied.

[WayneEDick]

Hi All, I really want to give a +100 to this effort. This has been a real pest for a long time, I thank you for addressing it. Best, Wayne

…

On Mon, Oct 8, 2018 at 9:16 AM Alastair Campbell ***@***.***> wrote: Updated based on the call, mainly to simplify the example. The example is now a fixed width 320px container, so the URLs obviously go out of the container without the toggle applied. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#486 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH0OF2hXxxuz_PtSnpyr_ojS4jI1n8-Rks5ui3p5gaJpZM4W5oPL> .