Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Support an attribute like aria-posindom that lets us modify a11y tree without modifying DOM order #1021

Open
mertdeg2 opened this issue Jul 22, 2019 · 11 comments
Open

Support an attribute like aria-posindom that lets us modify a11y tree without modifying DOM order #1021

mertdeg2 opened this issue Jul 22, 2019 · 11 comments
Milestone
ARIA 2.0

Comments

@mertdeg2
Copy link

mertdeg2 commented Jul 22, 2019 •
edited

In some cases, we would like to avoid modifying DOM order to make sure accessibility tree is in correct shape.

There might be a CSS rule that would break if the DOM order has changed. Attributes like aria-owns are good because it lets us modify the accesibility tree without having to modify the DOM order.

But to give developers full control, it would be nice if something like below existed.

<div>
  <button aria-posindom=1>first button</button>
  <button aria-posindom=0>second button</button>
</div>

And Chrome accessibility tree would be something like below:

GenericContainer
 - second button
 - first button
@carmacleod
Copy link
Contributor

This sounds very similar to setting tabindex to positive integers, which is historically problematic.
i.e. in the following, does second button come before very first button? Where does middle button go?

<button>very first button</button>
<div>
  <button aria-posindom=1>first button</button>
  <button>middle button</button>
  <button aria-posindom=0>second button</button>
</div>

That said, I still think the idea has merit. Currently, some browsers work around CSS reordering, and some don't, making for an inconsistent cross-browser experience. Something like what you are suggesting could help tighten up the spec. However, it would have to be carefully and fully specified. For example, I think it should only apply to elements within the same parent/ancestor, so that it is limited in scope. It might even be helpful for the parent/ancestor to inform the browser that (some of?) its children/descendants will have their accessibility tree order specified.

Points to consider and clarify:

  • not just for focusable/interactive content (i.e. DOM/a11y tree order affects reading order as well)
  • how would this interact with aria-owns ordering?
  • 0-based or 1-based numbering? (i.e. perhaps the parent/ancestor could use aria-posindom=0 to denote that it is the "anchor" for some reordered children/descendants)
  • what happens if numbers are skipped? repeated? (author error, so would need to specify fallback)
  • see also Consider the future of aria-flowto #630 for examples of other points to consider, i.e. how would this interact with aria-flowto?

@jnurthen jnurthen added this to the ARIA 1.3 milestone Aug 1, 2019
@carmacleod carmacleod added the F2FCandidate Candidate topics for F2F (or Virtual F2F) meeting label Aug 1, 2019
@carmacleod carmacleod mentioned this issue Aug 1, 2019
Closed
@joanmarie
Copy link
Contributor

Potentially related to this is the use of aria-owns which may or may not modify the accessibility tree depending on the user agent. Last time I checked, Gecko respects aria-owns to reorder the tree; WebKit and Blink do not (this assertion needs sanity checking).

@aleventhal
Copy link
Contributor

Blink reorders the tree from aria-owns.

@joanmarie
Copy link
Contributor

Confirmed. I stand corrected. Thanks @aleventhal!

@joanmarie
Copy link
Contributor

So test case:

<body>
  <div aria-label="buttons" role="group" aria-owns="2 1"></div>
  <button id="1">foo</button>
  <button id="2">bar</button>
</body>

When I look at the resulting accessibility tree for both Blink and Gecko, I see the object with the group role has two children:

  1. The "bar" button
  2. The "foo" button

@carmacleod would that solve your use case if WebKit also did it? If so, yay. If not, what else do we need to handle?

@joanmarie
Copy link
Contributor

I did a slightly different version of this to match what's in the opening report:

<body>
<div aria-label="buttons" role="group" aria-owns="2 1">
  <button id="1">foo</button>
  <button id="2">bar</button>
</div>
</body>

And I get the same results as in the previous comment, namely the children are reordered.

@LJWatson
Copy link

LJWatson commented Aug 1, 2019

This attribute would put the burden of fixing tab/a11y order on authors, and I don't think that's a good thing to do.

I'd be curious to see some examples where the disconnect is happening in the whild, and where rewriting the DOM would be too expensive to be feasible.

If there is a problem to solve, it seems to me that browsers should be where that happens. It should be possible for browsers to create a tab/a11y order that matches the visual order of content, where it's been rearranged using one of the relevant CSS properties. Firefox did this to some extent when flexbox was released, though they later reverted that capability unfortunately.

A new property would be needed to let authors declare whether the items in the container should have their tab/a11y order rearranged to match the visual order, because there are times when the disconnect is useful. But a single CSS property that is applied to the container, would be much easier for authors on the whole.

@jnurthen jnurthen added F2F Topics For F2F (or virtual F2F) and removed F2FCandidate Candidate topics for F2F (or Virtual F2F) meeting labels Sep 3, 2019
@carmacleod
Copy link
Contributor

carmacleod commented Sep 16, 2019 •
edited

Hi @LJWatson

It should be possible for browsers to create a tab/a11y order that matches the visual order of content, where it's been rearranged using one of the relevant CSS properties. Firefox did this to some extent when flexbox was released, though they later reverted that capability unfortunately.

I looked into this, and I'm afraid that ship has sailed.
This MDN article about ordering has several pertinent quotes:

  1. From the CSS spec for flex:

    Note: The reordering capabilities of flex layout intentionally affect only the visual rendering, leaving speech order and navigation based on the source order. This allows authors to manipulate the visual presentation while leaving the source order intact for non-CSS UAs and for linear models such as speech and sequential navigation.

  2. Also from the CSS spec:

    Authors must not use order or the -reverse values of flex-flow/flex-direction as a substitute for correct source ordering, as that can ruin the accessibility of the document.

  3. Regarding Firefox reverting its "follow the visual order" support:

    Note: For some years Firefox had a bug whereby it would attempt to follow the visual order and not the source order, making it behave differently to other browsers. This has now been fixed. You should always take the source order as the logical order of the document as all up-to-date user agents will be following the specification and doing so.

@joanmarie

@carmacleod would that solve your use case if WebKit also did it? If so, yay. If not, what else do we need to handle?

Yes, I think it would. We could add guidance (in ARIA and/or APG) strongly recommending that authors always ensure that the source order follows the visual order, but if they really need to reorder visually (and if for some reason, they can't reorder the DOM), they should match the order using aria-owns.

@cookiecrook Do you foresee a problem adding "aria-owns reorders tree" capability to WebKit?

For a very quick test, paste the following line into the browser's URL bar:

data:text/html,<div aria-label="buttons" role="group" aria-owns="2 1"><button id="1">foo</button><button id="2">bar</button></div>

In both Blink and Gecko, the accessibility tree is reordered as 'bar', 'foo'.

@jnurthen jnurthen modified the milestones: ARIA 1.3, ARIA 2.0 Mar 1, 2021
@jnurthen
Copy link
Member

jnurthen commented Mar 1, 2021

This is certainly not going to be in 1.3 - adding the 2.0 milestone for now.

@jnurthen jnurthen added deep-dive and removed F2F Topics For F2F (or virtual F2F) labels Mar 1, 2021
@jnurthen
Copy link
Member

@cookiecrook where is webkit on tree reordering with aria-owns. Can we close this if webkit has moved forwards?

@cookiecrook
Copy link
Contributor

@jnurthen wrote:

where is webkit on tree reordering with aria-owns.

https://webkit.org/b/223798

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
ARIA 2.0
Development

No branches or pull requests
7 participants
@cookiecrook @aleventhal @jnurthen @joanmarie @carmacleod @LJWatson @mertdeg2