Clarify adding additional whitespace

[xi]

Consider the following two HTML snippets:

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

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

The text node between the two <div> elements (containing only whitespace) in the first snippet does not influence the visual result. However, the accessible name (according to the current spec) of the first snippet would be "foo bar", that of the second "foobar".

The current algorithm leaves all control with authors. However, many authors are not aware that this kind of whitespace is significant. Many browsers add additional whitespace around block elements to counter this inconsitency. There are some questions about this:

• There is more than just block and inline. In which cases do we add additional whitespace? table? inline-block?
• Should CSS be considered when calculating the display property or should the initial value be used?

[johnfoliot]

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

Just curious... is it the whitespace, or the line-break that is causing the different outcomes. I agree that different outcomes is not great, but want to ensure what exactly is causing the difference... JF

…

On Sat, Feb 10, 2018 at 8:13 AM, Tobias Bengfort ***@***.***> wrote: Consider the following two HTML snippets: <div>foo</div> <div>bar</div> <div>foo</div><div>bar</div> The text node between the two <div> elements (containing only whitespace) in the first snippet does not influence the visual result. However, the accessible name (according to the current spec) of the first snippet would be "foo bar", that of the second "foobar". The current algorithm leaves all control with authors. However, many authors are not aware that this kind of whitespace is significant. Many browsers add additional whitespace around block elements to counter this inconsitency. There are some questions about this: - There is more than just block and inline. In which cases do we add additional whitespace? table? inline-block? - Should CSS be considered when calculating the display property or should the initial value be used? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABK-c-H_5ieAFXjPb7tVl4lIXJYI_ATKks5tTaQUgaJpZM4SA8OB> .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. [email protected] Advancing the mission of digital accessibility and inclusion

[xi]

The linebreak (i.e. a \n character) is whitespace.

[mcking65]

Resolving this issue completely is a major project. It will require changes outside of accname. To start, ARIA itself does not yet address the semantic implications of block vs inline. The use of block elements for visual positioning does not necessarily mean that the elements should be treated as blocks from a semantic perspective.

Because of the scope and complexity of this project, per discussion in the March 1, 2018 ARIA WG caucus, it is not containable in the accname 1.1 timeline. It is a high priority for accname 1.2.

[accdc]

I agree that the scope of adding this to the spec isn’t feasible at this time. However browser implementers are making these decisions right now regardless because they have to, so I strongly encourage leaving this functionality within the functional AccName Prototype code for this reason so at the least we have a positive example of what is expected in practice. All of the areas where this is ambiguous are documented within the code so browser implementors can make their decisions using informed comparative analysis. Otherwise, if omitted, and browser implementers strictly follow only what is implied and do nothing else, when this functionality is documented at a later date everybody will already be doing something different and have to change everything yet again to accomplish what should already make sense in practice right now, which leads to more confusion and time and money to fix. From: Matt King <[email protected]> Sent: Thursday, March 08, 2018 12:24 AM To: w3c/accname <[email protected]> Cc: Subscribed <[email protected]> Subject: Re: [w3c/accname] Clarify adding additional whitespace (#3) Resolving this issue completely is a major project. It will require changes outside of accname. To start, ARIA itself does not yet address the semantic implications of block vs inline. The use of block elements for visual positioning does not necessarily mean that the elements should be treated as blocks from a semantic perspective. Because of the scope and complexity of this project, per discussion in the March 1, 2018 ARIA WG caucus, it is not containable in the accname 1.1 timeline. It is a high priority for accname 1.2. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/ABx1aANSl-70DKC1wUDAUMrWGxKzx9AGks5tcOqggaJpZM4SA8OB> . <https://github.com/notifications/beacon/ABx1aKx593zDTG4qJ6py5PknpmhHVO7lks5tcOqggaJpZM4SA8OB.gif>

[joanmarie]

Another case we need to address as part of whitespace clarification:

<label> <input type="checkbox"> Make this the <em>top</em>most element</label>.

It is expected that there will be no space between "top" and "most."

[accdc]

It is expected that there will be no space between "top" and "most."

I ran this code using the AccName prototype and got the following. accName: "Make this the topmost element" accDesc: "" (Running Name Computation Prototype version: 1.15) From: joanmarie <[email protected]> Sent: Thursday, March 15, 2018 1:37 PM To: w3c/accname <[email protected]> Cc: Bryan Garaventa <[email protected]>; Comment <[email protected]> Subject: Re: [w3c/accname] Clarify adding additional whitespace (#3) Another case we need to address as part of whitespace clarification: <label> <input type="checkbox"> Make this the <em>top</em>most element</label>. It is expected that there will be no space between "top" and "most." — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/ABx1aJh1GxhnEau8sToHyri8vIj6Jx7jks5tetDpgaJpZM4SA8OB> . <https://github.com/notifications/beacon/ABx1aB6KbGHtE12SV-1oXGXZJGXwL2d6ks5tetDpgaJpZM4SA8OB.gif>

[joanmarie]

Cool @accdc. Then maybe that's already solved. There was an Editor's note about that use case indicating that it needed to be addressed, so I added it here. Thanks for the info!!

[xi]

It is expected that there will be no space between "top" and "most."

I ran this code using the AccName prototype and got the following.

I am a bit confused by that sentence. Is this prototype a normative part of the spec? If so, why is it not mentioned anywhere in the document?

This whitespace issue is clearly not addressed anywhere in the spec document in this repo.

[accdc]

"I ran this code using the AccName prototype and got the following."
"I am a bit confused by that sentence. Is this prototype a normative part of the spec? If so, why is it not mentioned anywhere in the document?"

No, it's not normative as yet, but it's one of the things that we are trying to work out for implementors since it's an important consideration that needs to be addressed. As Matt pointed out though, this will need to be added to the 1.2 milestone where normative criteria can be documented, because there isn't time to put it into 1.1.

The AccName Prototype is the same one that you contributed to earlier at
https://github.com/whatsock/w3c-alternative-text-computation

This code is being used as a prototype so that we can work out any flaws in the logic of these processes in advance by having a working algorithm to test with, and is executable from each of the testable statements documented on the wiki at
https://www.w3.org/wiki/AccName_1.1_Testable_Statements

In this way, we can end up with a working model of the naming computation that will always produce the same results for the same tests within all browsers, and browser venders can use this to test against in order to bring them into alignment. This is why it's important to include the whitespace logic at this time, since the goal here is also to have an algorithm that does as much as possible to reflect the most desirable results, because then, these conclusions about what works and what doesn't in practice will more accurately shape the normative guidance when we update this.

[JAWS-test]

If I am not mistaken, the AccName does not currently clearly regulate whether two adjacent nodes are output with or without spaces. What is clear is that they are output with spaces if there is a space, line break, tab character, etc. between them in the source code.
I suggest the following:

• HTML elements with implicit display:inline (span, i, strong etc.) are output without spaces.
• All other HTML elements (i.e. with implicit display:inline, display:inline-block, dispkay:table, e.g. img, p, div) are output with spaces.
• The CSS (e.g. span display:block) should not change the output (i.e. CSS assignments should be ignored).
• I'm unsure if ARIA roles should change the output (e.g. span role=button), but tend to say the same as for CSS: No

These suggestions differ slightly from the output of https://whatsock.github.io/w3c-alternative-text-computation/Editable%20Live%20Input%20AccName%20Test.html .

In my opinion it does not make sense to use the current output of the screenreaders for the AccName rule regarding space, because it is inconsistent. In the examples below, for example, Tab Navigation outputs some links with the label "12", but the same links are output when reading with the arrow keys in two reading steps with "1" and "2" (tested with JAWS 2019 and Chrome 77).

Reason: HTML elements have a meaning that should be considered by AT. CSS, with a few exceptions, is only used for visual design and is ignored by AT. I plead for not weakening the clear separation between HTML and CSS. A web developer who uses the wrong HTML elements and thus causes a wrong output of spaces violates the SC 1.3.2 of WCAG: Failure of Success Criterion 1.3.2 due to using white space characters to control spacing within a word.

Regardless of whether my suggestion is accepted or not, I am very much in favour of the correct output being regulated bindingly in AccName, because without regulation it is unclear how it would be correct.

My suggestion would mean that the following links would be output with or without spaces between 1 and 2 as follows

without space

<a href=#><span>1</span>2</a>
<a href=#><span>1</span><span>2</span></a>
<a href=#><span>1</span><span></span><span>2</span></a>
<a href=#><span>1</span><span hidden>3</span><span>2</span></a>
<a href=#><span>1</span><!--3--><span>2</span></a>
<a href=#><span style="display:block">1</span><span style="display:block">2</span></a>

with space

<a href=#><span>1</span> <span>2</span></a>
<a href=#><span>1</span><span> 2</span></a>
<a href=#><span>1</span><br><span>2</span></a>
<a href=#><span>1</span>
<span>2</span></a>
<a href=#><div>1</div>2</a>
<a href=#><div>1</div><div>2</div></a>
<a href=#><div style="display:inline">1</div><div style="display:inline">2</div></a>
<a href=#><div style="float:left">1</div><div style="float:left">2</div></a>

needs to be discussed

<a href=#><span role=heading>1</span><span  role=heading>2</span></a>
<a href=#><span>1</span><hr role=presentation><span>2</span></a>

[eps1lon]

If I am not mistaken, the AccName does not currently clearly regulate whether two adjacent nodes are output with or without spaces.

I think it's only unclear in 2.F.iii:

Append the result to the accumulated text.

Every other mention of "append the result" explicitly states whether a Space is added or not.

From what I can tell implementors interpreted this omission as "block" -> "Space", "inline" -> "no Space".

[JAWS-test]

In this context, the new CSS values for display, such as flex and grid, should also be considered, since the current output in Firefox, Chrome and Edge is wrong: FreedomScientific/standards-support#421

[accdc]

Hi,
I've been considering how this might be added within the Core AccName algorithm, and would like to propose the following, not as spec text yet, but as the concept for review.

The Core AccName algorithm is not meant to be user agent specific, so it doesn't actually need to define and quantify all native host semantics where this concept may be variable when rendered by different technologies, because these differences will already be documented within the host spec using Core AccName as the baseline.

As pointed out here, there are many ways visual rendering differences can be achieved depending on which technology is being used to do this, and the purpose of AccName is not to confine or restrict how content is rendered, or to ignore when these changes occur, but rather to represent an accessible human readable string from that content so it can be added within the accessibility tree.

It seems like it may be useful to step back for a moment, and simply state what the ultimate purpose of this should be. Then it will be easier to define how this can be stated to make sure this purpose is conveyed as needed within the spec.

So, to me, this is how it makes sense.

When computing the name for an element, the accessible name as computed should insert a space between textual content that is visibly separated when rendered, so that the meaning of the accessible name or description matches the intuitive flow of the text that is human readable.

It seems to me that the above statement best represents what is needed to produce the most accessible names and descriptions, because the goal here is not to debate what computers can understand, but rather what people will best understand when they hear these things announced.

Regarding the Core AccName algorithm, it can be explicitly stated that, when computing the accessible name or description of an element, all owned elements that are visually perceived as being separated from adjacent content, must include a single space to separate them when computed as a flat string of text.

Like I said, this isn't spec text, but it cuts to the core of the issue, which is to provide an equally accessible experience for non-sighted screen reader users when attempting to perceive the same content, and to perceive the same level of understanding of that content as it is announced verbally. It is a simple logic test to read allowed what is visually displayed and ask yourself, would that make sense if I couldn't see it?

The explicit definitions of what constitutes visual separation will need to be handled within the specs that deal with specific host semantics, such as block level versus inline elements and special characters in HTML, or block level versus inline styling pseudo elements and special characters in CSS, and the same in SVG.

First, we define the baseline behavior within the Core AccName algorithm, then it can be explicitly defined as it needs to be within specific user agents to handle native host semantics, and then these are added into the browsers so it can be accurately represented to assistive technologies like screen readers.

Can we agree that this is a viable way to move forward?

Thanks,
Bryan

[xi]

Hi Bryan,

I mostly agree that visual separation is a good indicator for semantic separation and that the details can be left to the host specs. But I also have some notes on both:

• I can think of cases where visual separation is conveyed by means other than space. Example:

  <style>
      div {
          float: left;
      }
      body :nth-child(even) {
          color: white;
          background: black;
      }
  </style>
  
  <div>One</div>
  <div>Two</div>
  <div>Three</div>

  

  I am wondering whether we should really focus on the visuals or if there is some more abstract layer of "truth" behind it that we could use. Probably not.

• Whether something is defined in the Core AccName algorithm or in the host spec is not a binary question. For example, there could be some rough guidelines in core that need to be fleshed out in the host spec. In any case, the relation between the two should be explicit (see Relation to HTML-AAM not obvious #8).

[accdc]

I understand what you mean, and agree that visual separation is a tall order in all cases. I don't believe that absolute conformity is possible in such cases where visual aspects are used as the only guiding principles.

"I am wondering whether we should really focus on the visuals or if there is some more abstract layer of "truth" behind it that we could use."

Though it's not possible to ensure that every case will be perfect when it comes to computing accessible names and descriptions, it is possible to ensure that block level styling will at least be a contributing factor when it comes to automatically computing when some spacing should be added.

At present, adding support for this within the 1.2 spec is a priority that we've been discussing for a while now, including both elements and CSS pseudo elements. It will never be 100% perfect in all cases, but it will cover the majority of general use issues that we encounter often already.

Accounting for whitespace characters within specific rendering environments, such as   in HTML and many others, will also need to be observed in those related specs as well. I think that whitespace characters that need to be rendered like this do need to be defined within the native host specs where they apply. Otherwise the core AccName spec will become hopelessly complicated.

Defining what basic whitespace means is a bit of a separate issue, which is another aspect of the spec that needs to be changed to better conform with other specs and to act as a baseline for its definition.

From the initial list of whitespace characters documented in the HTML spec, can you recommend any additions to it that would be helpful as a core set of characters to check for?

[carmacleod]

Not sure if this draft specification of aria-textseparation is helpful here, but for info, the ARIA WG was considering allowing authors to override the default (based on style) text separation by explicitly setting a value for aria-textseparation that best describes how their elements should be separated.

For the OneTwoThree example above, assuming the same css, the markup to ensure that AT read it as "One Two Three" would be:

<div>One</div>
<div aria-textseparation="space">Two</div>
<div>Three</div>

If you think this new attribute would be helpful, and if you would like it finalized in time for ARIA 1.3, please add a comment to w3c/aria#996.

[xi]

Newer issue: #225. I am closing this so discussion happens in a single place.