search

w3c / aria

Accessible Rich Internet Applications (WAI-ARIA)
https://w3c.github.io/aria/
Other
631 stars 119 forks source link

Inconsistent use of "owned by" #1161

Open WilcoFiers opened 4 years ago

WilcoFiers commented 4 years ago

Reading through the document, there seem to be cases where "owned by" is meant to be either all descendants (as defined) but there are other places where it is strongly implied "owned by" is a parent/child relationship. Firstly, the definition:

Owned Element An 'owned element' is any DOM descendant of the element, any element specified as a child via aria-owns, or any DOM descendant of the owned child.

But then if we read menuitem, it says the following:

menuitem (role) In order to identify that they are related widgets, authors MUST ensure that menu items are owned by an element with role menu or menubar, or by a role group which itself is owned by an element with role menu or menubar.

This last part "or by a role group which ..." doesn't make sense if "owned by" applies to all descendants. If a menu item owns all descendants, it automatically owns a menuitem owned by a group that's a child of the menu. The menuitem even owns it, if it's in a list which is in a grid which is in a header which is in a menu.

And that last part is where I'm starting to have proper concerns. The following seems to be conform to ARIA 1.2:

<div role="menu">
  <div role="list">
    <div role="header">
      <div role="menuitem">
        <div role="listitem">Tower of oddly nested roles</div>
      </div>
    </div>
  </div>
</div>

Even more explicitly, 9.2 basically says that elements are only supposed to have one owned element:

9.2 States and Properties

  1. Correct usage with regard to DOM tree structure, such as an element being owned by more than one other element.

On the other hand, there are places where it matters that "owned elements" aren't just the child elements, but all descendants (or at least, up to a certain level):

If aria-readonly is set on an element with role grid, user agents MUST propagate the value to all gridcell elements owned by the grid and expose the value in the accessibility API.

In this case, it matters that aria-readonly propagates to the cell of a grid. Although even here it could be argued that aria-readonly shouldn't propagate down into nested grid elements. That propagation is far more pronounced for the presentation role, and here it really matters if "owned elements" is limited to children, or all descendants:

presentation (role) When an explicit or inherited role of presentation is applied to an element with the implicit semantic of a WAI-ARIA role that has required owned elements, in addition to the element with the explicit role of presentation, the user agent MUST apply an inherited role of presentation to any owned elements that do not have an explicit role defined.

As far as I can tell, browser vendors have taken this to mean all children, and everything directly referenced through aria-owns. That's very sensible, otherwise a single misplaced role="presentation" on the body element could wrack the semantics of the entire page.

Proposal

I think the simplest solution here would be to split the "owned elements" definition, into "owned children" and "owned descendants". That seems to address most of these issues. Additionally, you'd have to do something about "presentation" and "none", make it clear those elements can't "own" anything.

We'd also get an answer on whether or not "generic" should be included in the accessibility tree or not. Browsers don't seem to agree on that.

A final little bonus thing would be to make it explicit that element referenced with "aria-owns" are owned children of the first element with that attribute, and that other elements can not own them.

JAWS-test commented 4 years ago

Your explanations do not seem to be right for role=presentation, because this only affects "required owned elements". In a table, for example, it affects <tr> and <td>, but not to the elements within the table (nor to nested tables). However, "required owned elements" is somewhat imprecise, since, for example, <th> is not a required element for a table, but is also affected by role=presentation. A role=presentation at the <body> has no effect, because <body> has no required owned elements.

Better would be: If a required ancestor element has a role=presentation, this is also inherited to the current element.

carmacleod commented 4 years ago

The ARIA Working Group just discussed Inconsistent use of "owned by".

The full IRC log of that discussion <carmacleod> github: https://github.com/w3c/aria/issues/1161
<carmacleod> jamesn: waiting on me
jnurthen commented 3 years ago
Discussed in 11/12/2020 WG Meeting **JN:** ok, 1161, inconsistent use of owned by … Scott had a pull request, 1213, which still has a bunch of comments in it … I think we need someone to take over this pull request > *jamesn:* [https://github.com/w3c/aria/pull/1213](https://github.com/w3c/aria/pull/1213) > *carmacleod:* PR: [https://github.com/w3c/aria/pull/1213](https://github.com/w3c/aria/pull/1213) **CM:** all right, I'll take over **MK:** I'm just looking at this quickly, but is the generic role considered presentational? **JN:** a generic role is not presentational, I do not believe **MK:** I just kind of wonder in this PR, I'm looking at Scott's summary and I'm wondering if it should be presentational or generic (instead of just presentational) … if we're doing presentational we should do generic as well … it seems to me it should be that presentational or generic things should just be empty containers, or empty except for the context **JN:** I know you're essentially trying to avoid people having to do `
` which you have to in many places **MK:** I want to make sure it's allowed to have an empty div even with role="none" because there was some interpretation of this that it needed to be a direct descendant, and I think it needs to be a direct descendant in the a11y tree and any divs should be ignored … I'm thinking back to Alice and her efforts to standardize the a11y tree and the differences between Chrome and Firefox or Chrome and Webkit **JD:** just as a clarification, about a year ago there was a bunch of a11y tree pruning, so I no longer complain about that **JC:** there's still a ton of differences between the trees, and the bunch of divs Matt mentioned can still cause problems, and it's unclear whether that should be resolved in browser engines or ATs, but we should clarify the a11y tree regardless **JN:** This PR is attempting to define which elements are allowed as intermediate containers between things that have required owned elements, is that correct: **JC:** one of the challenges is even if you have a generic one like a div, if it has style props associated with it like layering and bounds it has to be exposed to the a11y tree in order to compute the position for things like VO cursor, so we can't just take it out without breaking everything … so if a user includes them but doesn't add something like role="none" or role="presentation" a lot is left up to the browser engine **JN:** so maybe authors do need to add role="none" but we should at least clarify that so authors know that **JC:** that puts a lot of onus on the author, but that would at least make it clear **JN:** if tools can check it, that at least makes it clear that they have made an error **MK:** I think ARIA doesn't distinguish between div, span, and address in HTML but it feels really onerous to require role="none" on a div in between a gridcell and a row **JN:** I agree, and I've hit these errors so many times. Realistically at the moment it's the only solution we have today without getting browser engines to change **MK:** I don't know, it seems like this issue is calling out whether or not we have to do that, and whether or not we put that in the spec … I don't know if I'd object if it really is truly necessary, but it's hard for me to understand why it's truly necessary **JC:** James, your comment about not getting browser engines to change, we should certainly strive to get browsers to change when necessary. In this case, I think it's not entirely clear what the browser should do if it were to change. … I think we'd have to get AT developer buy-in on those as well, because sometimes when we've changed some of those things in the past it's broken something down the line … according to priority of constituency it's something we should change, authors over implementors **JN:** But if we specify that style attributes affect things, we crawl into this place where someone adds another stylesheet to your page and suddenly everything's broken **JC:** I think we need to just specify that it's just always required, or we need to add some specific advice for implementors, and I think I lean towards implementors more … because we're always going to have authors who put something like a button between cells **JN:** if we can, that seems awesome, but compared to everything else we have to solve, it seems like we have a hard time getting implementors to agree on … Carolyn, thanks for volunteering to give this a go
spectranaut commented 1 year ago

Revisit this after Sarah's PR lands: https://github.com/w3c/aria/pull/1454/files

spectranaut commented 1 year ago

1454 landed and removed "required owned element".

There are many uses of "owned elements" which should probably be reconsidered and maybe replaced. For example, in spinbutton:

Authors MAY create a spinbutton with children or owned elements, but MUST limit those elements to a textbox and/or two buttons.

Should we simply say "with accessibility children" or "with children" or (maybe) "with owned elements"?

Additionally, "owning element" is not used in the spec, except in tooltip where it's meaning is not even the definition of "owning element":

The tooltip typically becomes visible, after a short delay, in response to a mouse hover, or after the owning element receives keyboard focus

spectranaut commented 1 year ago

Discussed in F2F meeting yesterday: https://www.w3.org/2023/05/04-aria-minutes#t01

It was decided to remove the terms "owning elements" and "owned element" (especially as owned element is not used) and replace use in the document with the appropriate defined term, with "accessibility child", "accessibility parent" or "accessibility descendant"

This work is blocked on: https://github.com/w3c/aria/issues/1150#issuecomment-1536859008