Issues with the naming computation and parsing nested element structures including CSS pseudo elements

Thanks. I'm renaming this thread and opening this discussion up to the rest of the ARIA group because it seems to expose some important inconsistencies in the spec.

"Bryan, Chrome is not adding space around <img alt="foo"> to names of ancestors."

I understand, the issue however referred to both CSS pseudo elements and objects such as images, as well as hypothetical other objects such as embedded form fields, links, and other independent objects that may occur as valid children of parent structures where this same issue applies.

So in the case of Chrome Canary, the following is returned for the example I included.

"It's a fact the moonCresent Europais really really big so there." // Chrome Canary adds spaces between the pseudo element text and the DOM text nodes, even though there are none in the markup.

This seems to be contrary to common practice as well. For instance, I can't find anywhere where it states in the WCAG that the alternative text for all named images must include extra blank spaces at the beginning and end of every image description to prevent the alternative text from being automatically concatenated with adjacent element names in the naming computation for parent controls in the accessibility tree.

This also appears to contradict the spec where it states at the end of the naming computation algorithm the following:

"Append the result of each step above, with a space, to the total accumulated text."
http://www.w3.org/TR/accname-aam-1.1/


Which steps is this referring to if not the parsing algorithm?

I'm working on updating the recursive naming algorithm at
https://github.com/accdc/w3c-alternative-text-computation

So I'm trying to hammer out these interpretations for the JavaScript naming computation simulator.

This example too appears to break across browsers:

<label><span>ARR</span><input type="text" id="formId" /><label for="formId">is Pirate for "arr".</label></label>

In such a case, is only one label to be parsed? If yes, which label takes precedence, or if both are parsed, which one is to be processed first?

Also, if both are meant to be parsed, then the following text from the naming computation is applicable:

"Important:  Each  node  in the subtree is consulted only once. If text has been collected from a descendant, but is referenced by another IDREF in some descendant node, then that second, or subsequent, reference is not followed. This is done to avoid infinite loops."

In such a case, what is the string name for this form field according to the naming computation?

Thanks,
Bryan


Bryan Garaventa
Accessibility Fellow
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com
415.624.2709 (o)
www.LevelAccess.com

From: Aaron Leventhal [mailto:aleventhal@google.com]
Sent: Wednesday, January 31, 2018 1:19 PM
To: Bryan Garaventa <bryan.garaventa@levelaccess.com>
Cc: Tobias Bengfort <tobias.bengfort@posteo.de>; Alexander Surkov <asurkov@mozilla.com>; Marco Zehe <marco.zehe@gmail.com>; david bolter <david.bolter@gmail.com>; James Craig <jcraig@apple.com>; Dominic Mazzoni <dmazzoni@google.com>; Matthew King <mck@fb.com>
Subject: Re: a11y-outline available for firefox

Bryan, Chrome is not adding space around <img alt="foo"> to names of ancestors.

Aaron

On Wed, Jan 31, 2018 at 12:21 PM Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>> wrote:
Not two issues, both apply whether they are CSS pseudo elements or embedded images with accessible names via alt, aria-label, or title. If combined like this all of the browsers are adding spaces in the naming computation presently.

If this is incorrect, then there needs to be agreement in implementation so that validation tools can simulate this algorithm correctly.

Bryan Garaventa
Accessibility Fellow
Level Access, Inc.
Bryan.Garaventa@LevelAccess.com<mailto:Bryan.Garaventa@LevelAccess.com>
415.624.2709<tel:(415)%20624-2709> (o)
www.LevelAccess.com<http://www.LevelAccess.com>

From: Aaron Leventhal [mailto:aleventhal@google.com<mailto:aleventhal@google.com>]
Sent: Wednesday, January 31, 2018 8:00 AM
To: Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.com>>
Cc: Tobias Bengfort <tobias.bengfort@posteo.de<mailto:tobias.bengfort@posteo.de>>; Alexander Surkov <asurkov@mozilla.com<mailto:asurkov@mozilla.com>>; Marco Zehe <marco.zehe@gmail.com<mailto:marco.zehe@gmail.com>>; david bolter <david.bolter@gmail.com<mailto:david.bolter@gmail.com>>; James Craig <jcraig@apple.com<mailto:jcraig@apple.com>>; Dominic Mazzoni <dmazzoni@google.com<mailto:dmazzoni@google.com>>; Matthew King <mck@fb.com<mailto:mck@fb.com>>

Subject: Re: a11y-outline available for firefox

Are we talking about 2 different issues here? Spacing around pseudo elements vs. spacing around an image?
Around psuedo elements:
- It looks to me that all 3 implementations got spacing around the pseudo element incorrect, because there shouldn't be any.
Around images:
- It looks like only Chrome got spacing around the <img> correct, because there shouldn't be any. I don't see anything in the ACCNAME spec that says it should be added, and from a practical point of view this allows the author to choose whether to add space or not. If we always add space where there wasn't any, how can the author replace a substring within a word with an image? Not that it's that useful, but it's hard to predict what people want to do.

Aaron

Received on Thursday, 1 February 2018 01:18:08 UTC