Mention <br> element

[xi]

<div>foo<br>bar</div>

I would expect the accessible name of that element to be "foo bar" (with a space where the <br> element was). However, I do not see how the <br> element is handled in the spec.

Maybe a step roughly like this could be added between 7 and 8:

Otherwise, if the current node represents some kind of whitespace (e.g. the <br> element in HTML), return a string containing a single space.

[accdc]

I agree, this seems like a no-brainer to me. If text is broken out on different lines via BR then this cannot be concatenated with no space between lines when computed. Though I’m not sure how this could be included in the spec, it does need to be included in the naming computation implemented by the browsers. As such, I’ve already added the ‘br’ tag to the block level elements array in the Naming Computation Prototype at https://raw.githubusercontent.com/accdc/w3c-alternative-text-computation/c7863b6f9e00616b4c24e263719b76765046eabe/docs/Sample%20JavaScript%20Recursion%20Algorithm/recursion.js

[AmeliaBR]

I think it is a fair simplification to say that a <br> element is equivalent to CSS generated content of a line break character (although the CSS working group has determined that existing behavior cannot be described so simply, and so it's currently "magic" behavior outside the CSS model).

However, as Bryan hinted at in his reply, the <br> is only one of many block-level elements that can break up a text. In script-generated DOM, you often won't have whitespace between other block elements, such as <p> or <li>. The name & description computations still need to insert whitespace for the visual break caused by the block layout.

So that should be a broader issue: if elements are displayed as separate blocks, insert one whitespace character between them. For CSS-styled content, that could basically be defined as: If an element's CSS display type is not inline, add whitespace before and after its text alternative when compiling a parent node's alternative text.

For environments without CSS styling, you would use the default display type for the element, which could be defined as lists of block vs inline elements (e.g, in the HTML-AAM).

If specific additional details are required for <br>, that should probably also go in the HTML-AAM, although maybe with an informative note in the text alternative computation section of this spec.

[xi]

<br> is only one of many block-level elements

I am not 100% sure, but <br> seems to get display: inline, at least in chrome. This is why I think it is special.

[accdc]

Hi, I didn’t mean to imply that BR is a block level element, just that BR has a definitive visual purpose which is to force a visual line break, and logically anything that is broken in such a manner must include a space in the naming computation when calculated by browsers. So by adding this tag to the block elements array, it forces this to occur in the Naming Computation Prototype that we are testing with.

[AmeliaBR]

I brought up block-level elements because they don't seem to be mentioned in the current spec text, and they have the same effect of breaking up text.

But yes, relying on CSS display to describe <br> would not be sufficient, since it is an inserted forced line break, not a new CSS box. Sorry for going off topic on that point.

My suggestion would therefore have 3 parts:

• In HTML-AAM's Accessible Name and Description Computation section, include an entry for <br> that clarifies that it is equivalent to a line break character.
• Clarify in AccName step 6 (where there is currently an Editor's note) that you need to add whitespace between the alternatives for block elements, but not between inline text spans.
• Add an informative note about <br> to AccName, explaining that even though it is inline, it has an alternative text equivalent to non-collapsible whitespace.

[AmeliaBR]

Maybe @stevefaulkner or @jasonkiss could comment on the plausibility of adding a <br> text equivalent to HTML-AAM, for use when computing parent text even though it has no role itself.

[mcking65]

The issue of how to process <br> issue is closely related to #3. It should not be addressed independent of all the other white space considerations, which, due to their complexity, are targeted for accname 1.2.

[accdc]

I’ve also added relevant comments to issue 3 for reference. From: Matt King <[email protected]> Sent: Wednesday, March 07, 2018 11:48 PM To: w3c/accname <[email protected]> Cc: Bryan Garaventa <[email protected]>; Comment <[email protected]> Subject: Re: [w3c/accname] Mention <br> element (#4) The issue of how to process <br> issue is closely related to #3 <#3> . It should not be addressed independent of all the other white space considerations, which, due to their complexity, are targeted for accname 1.2. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/ABx1aNCZChjz3rNnAYSR79Q6MChpnOv-ks5tcOI7gaJpZM4SA8Vp> . <https://github.com/notifications/beacon/ABx1aN_dldsmwdGpsIcMkccn6_4l4dSvks5tcOI7gaJpZM4SA8Vp.gif>