RE: CSS in Accessibility Name Computation (Was: a11y-outline available for Firefox)

Hi,
I agree this is complicated, and that emails alone won't solve everything. However, as we discussed in the ARIA Caucus earlier today, it is critical for us to agree on a single outline that is programmatically workable so it can translate into browser implementation, rather than what we have now where grey areas such as these are indefinite and loosely based on individual interpretation.

So what will go a long way to solving this, is for us to have a working prototype that simulates exactly what we can all agree should be happening, and this allows all of us to perform Realtime tests against, and to hammer out any unforeseen issues before they are added to the browsers.

As promised in the ARIA Caucus call today, such a prototype is now available, and I've matched all of its functionality with the naming computation steps and all relevant caveats. Also, within the comments of the code you will find detailed references to explain the logic where interpretations in the spec are loose or even undefined, and the logic that was applied to each.

GitHub repo clone, download, or fork: https://github.com/accdc/w3c-alternative-text-computation

Recursion algorithm prototype file: https://raw.githubusercontent.com/accdc/w3c-alternative-text-computation/894a7e11193fc0ae0ce53e991a42fd397ca14028/docs/Sample%20JavaScript%20Recursion%20Algorithm/recursion.js


Inclusions:


1. Embedded widget controls, where the value is computed and not the name. E.G if such is embedded within a heading. In such cases all native form fields are covered, as with all relevant ARIA widget constructs including all range controls, edit controls, and selectable controls such as listbox, tablist, grid, tree, and treegrid widgets.



Also, though not specified in the spec, if a form control is the originating node where this computation is being used to compute the label for itself, then the value is not included, because this would be confusing. Otherwise all values are computed in accordance with the spec.

2. Inline versus block level elements, which matches against not only the element types but all relevant CSS properties that cause block level formatting to occur on differing element types. An HTML5 element index has been added to cover all of these, plus a block-level CSS property map that is checked against during processing.

Also, CSS pseudo elements are tied into this as well, since it is possible to specify that pseudo elements can be either inline or block depending on their assigned properties, so logic is included here too so that block level pseudo elements are not concatenated without a buffer, where inline pseudo elements in contrast act normally with no buffer as expected.

3. Logic for handling nested label elements has been added, in which an implicit label element surrounds a form field that also includes an explicit form field reference somewhere else. There appears to be no standard in the naming computation to address this, so I set this to compute the explicit label and ignore the implicit one in such cases. This seems logical to me, but if everybody wants this to be handled differently it can be changed.

4. Same node duplication is enforced, in which case, if a node references another node that has already been processed as part of another iteration, then the node will only be processed once and ignored after that. This would occur if aria-labelledby was used to reference an adjacent node in the first ID ref, but then referenced the whole container with a second ID ref that included the node that was first processed just before that.

5. All aria-owns references are automatically followed as part of the same DOM structure during the recursive naming computation.

Also, any use of aria-owns that occurs upon nodes that don't support child elements is automatically aborted without processing the ID refs.

6. All hidden nodes that are nested children of the node being processed are not included in the computation, including any with CSS display:none or visibility:hidden, the 'hidden' attribute, or any use of aria-hidden="true".

I did not at this time include element nodes that are hidden but also include aria-hidden="false", because there appears to still be disagreement that this is meant to occur.

So if everybody agrees that hidden nodes like these that include aria-hidden="false" should be exposed in the naming computation, then I can add this to the prototype as well.

If a hidden node is directly referenced via aria-labelledby or aria-describedby however, it will be exposed regardless in accordance with the spec.

There are other finer details documented within the code, so please run tests and let me know if anything is working unexpectedly or needs updating. There may need to be some changes to the spec text to accommodate for what we agree should be happening.

Thanks,
Bryan


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

From: jcraig@apple.com [mailto:jcraig@apple.com]
Sent: Friday, February 02, 2018 1:54 PM
To: Matthew King <mck@fb.com>
Cc: Tobias Bengfort <tobias.bengfort@posteo.de>; Aaron Leventhal <aleventhal@google.com>; Alexander Surkov <asurkov@mozilla.com>; Bryan Garaventa <bryan.garaventa@levelaccess.com>; Marco Zehe <marco.zehe@gmail.com>; David Bolter <david.bolter@gmail.com>; Dominic Mazzoni <dmazzoni@google.com>; Joseph Scheuhammer <clown@alum.mit.edu>; Michael Cooper <cooper@w3.org>; Tess O'Connor <hober@apple.com>
Subject: CSS in Accessibility Name Computation (Was: a11y-outline available for Firefox)

New to this thread… I guess Matt cc’ed me? I trimmed the massive reply to recently relevant parts and updated the subject line. Adding Joseph Scheuhammer and Michael Cooper since this topic is in Name Comp space. Copying Tess from the Apple side.

To Matt’s points:

For standard ::before/::after pseudo-elements and probably with list marker ::before pseudo-elements (some of which can be complex), I think Name Comp can be solved with a few edits to the ACC-NAME spec. It seems like that’s what you were already working on earlier in the thread.

Those edits would need to be vetted by representatives from all four major rendering engines. (Track down active responses from members of this thread and the Microsoft team. No response should NOT count as acknowledgement.) I expect that Blink and WebKit’s implementations would be straightforward since the accessibility tree is built off the render tree and those engines already expose psuedo-element content to AT. I believe, however, that WebKit may be the only engine to expose psuedo-element alternative content to AT. I cannot speak to the implementation complexity in Mozilla, Trident, or Edge. When you think you have a good draft, we’d be happy to review it and vet with other WebKit implementors.

My longer-term recommendation is to have CSS-knowledgable accessibility implementors involved in the Houdini project. If the goal of that group is to standardize and extend CSSOM and hooks into the rendering process, it’s also the place to include CSS accessibility clarification for each feature, how it ties into render tree order and name computation. There are enough implementation differences between the browser engines that trying to standard the entirety of CSS’s accessibility impact in a separate, standalone mapping guide may be naïve or ineffective.

James



On Feb 2, 2018, at 12:18 PM, Matthew King <mck@fb.com<mailto:mck@fb.com>> wrote:

I am really concerned about the lack of clarity surrounding if/when/how CSS should effect name computation. I think we need a thorough discussion and consequent spec language. There are clearly many divergent views with significant consequences.

It seems that it would be valuable to start by seeking agreement on some general principles to use as guideposts if not hard and fast rules.

For example, I propose we start with the principle that authors use CSS to communicate the visual presentation and HTML/ARIA to communicate the semantic meaning of that presentation. In other words, any means of adding or removing space with CSS should not be part of the name calculation and authors should use markup that communicates the semantic spacing.

This would mean finally, at long last, clarifying the "default" semantic difference between span and div by mapping them to two different generic ARIA roles, one that communicates "inline" semantics and one that communicates "block" semantics. Then, we could have deterministic outcomes, e.g., spans are concatenated without space and divs are concatenated with space in the name calculation regardless of CSS. If the author wishes to use all spans but selectively override the implicit inline semantic on some spans by applying a role that gives it a block semantic, no problem.

Then we could avoid all the ambiguity that comes with trying to spec possible semantic meaning from different CSS techniques. For instance, one of the most annoying things is when words are spelled instead of spoken because of spacing. Right now, VoiceOver will do this in Safari as a result of padding.

Clearly there are some meaty issues that need attention and an email thread is not the way to resolve them.

We have a CSS mapping task force in ARIA. Should the discussion be there? Should this be a general ARIA topic? Does there need to be a swat team formed to really fix name calculation? I agree with Bryan that it is muddy, problematic, and the lack of clarity is causing real world problems.

Matt

-----Original Message-----
From: Tobias Bengfort [mailto:tobias.bengfort@posteo.de]
Sent: Friday, February 2, 2018 8:50 AM
To: Aaron Leventhal <aleventhal@google.com<mailto:aleventhal@google.com>>; Alexander Surkov <asurkov@mozilla.com<mailto:asurkov@mozilla.com>>
Cc: Bryan Garaventa <bryan.garaventa@levelaccess.com<mailto:bryan.garaventa@levelaccess.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>>; dmazzoniATgoogle.com<http://dmazzoniATgoogle.com> <dmazzoni@google.com<mailto:dmazzoni@google.com>>; Matthew King <mck@fb.com<mailto:mck@fb.com>>
Subject: Re: a11y-outline available for firefox

As we are already talking about display type, should not margins also influence the whitespace? Think of this example:

a:before {
 content: "(external)";
 margin-right: 0.5em;
}
<a>link</a>

As far as I understand, the current version would calculate the name to "(external)link" rather than "(external) link" even though visually there is a clear separation.

I understand that, with the same argument, you could also include paddings, borders, ans all sorts of other CSS in the calculation. My point is that either all of it should be included — or none.

thanks
tobias


On 02/02/18 16:29, Aaron Leventhal wrote:

The general rule being, if the CSS display type creates visual space
we need to add it into the name. In practice, there is a subset of
display types such as inline, inline-block that don't. We should
probably agree on the list of those.

Aaron

On Fri, Feb 2, 2018 at 10:26 AM Alexander Surkov <asurkov@mozilla.com<mailto:asurkov@mozilla.com>>
wrote:


Agreed. If no space is rendered between inlines, then no space should
be added for a name.