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

Inconsistent use of "owned by" #1161

Open
WilcoFiers opened this issue Jan 20, 2020 · 6 comments
Open

Inconsistent use of "owned by" #1161

WilcoFiers opened this issue Jan 20, 2020 · 6 comments
Assignees
@spectranaut
Labels
1.3-Blocking Blocking issues for 1.3 WRWD clarification clarifying or correcting language that is either confusing, misleading or under-specified WR comments
Milestone
2023

Comments

@WilcoFiers
Copy link
Contributor

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
2. 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
Copy link
Contributor

JAWS-test commented Jan 21, 2020 •
edited
Loading

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.

@jnurthen jnurthen self-assigned this Jan 23, 2020
@css-meeting-bot css-meeting-bot mentioned this issue Feb 27, 2020
Closed
@carmacleod
Copy link
Contributor

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

The full IRC log of that discussion <carmacleod> github: https://github.com//issues/1161
<carmacleod> jamesn: waiting on me

@scottaohara scottaohara mentioned this issue Mar 13, 2020
Closed
@carmacleod carmacleod mentioned this issue Mar 22, 2020
Closed
@jongund jongund self-assigned this Apr 2, 2020
@jongund jongund linked a pull request Apr 9, 2020 that will close this issue
Issue1161 inconsistent use of aria owns #1235
Closed
@jongund jongund mentioned this issue Apr 15, 2020
Closed
@jnurthen jnurthen added this to the ARIA 1.3 milestone Apr 16, 2020
@meldafert meldafert mentioned this issue Sep 1, 2020
Closed
@WilcoFiers WilcoFiers mentioned this issue Oct 9, 2020
Merged
6 tasks
@jnurthen
Copy link
Member

jnurthen commented Nov 18, 2020 •
edited by carmacleod
Loading

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: #1213

carmacleod: PR: #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 <div role="none"> 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

@jnurthen jnurthen added the 1.3-Blocking Blocking issues for 1.3 WRWD label Dec 16, 2020
@carmacleod carmacleod self-assigned this Dec 17, 2020
@carmacleod carmacleod removed their assignment Mar 4, 2021
@WilcoFiers WilcoFiers mentioned this issue Jul 8, 2022
Closed
@jnurthen jnurthen added the clarification clarifying or correcting language that is either confusing, misleading or under-specified label Aug 2, 2022
@spectranaut spectranaut assigned spectranaut and unassigned jnurthen Feb 6, 2023
@spectranaut
Copy link
Contributor

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

@spectranaut spectranaut mentioned this issue Feb 9, 2023
Open
@scottaohara scottaohara removed their assignment Mar 3, 2023
@spectranaut spectranaut mentioned this issue Apr 11, 2023
Open
@spectranaut spectranaut mentioned this issue May 1, 2023
Closed
@spectranaut
Copy link
Contributor

#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
Copy link
Contributor

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: #1150 (comment)

@spectranaut spectranaut mentioned this issue May 5, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@spectranaut spectranaut

Labels
1.3-Blocking Blocking issues for 1.3 WRWD clarification clarifying or correcting language that is either confusing, misleading or under-specified WR comments
Projects
None yet
Milestone
2023
7 participants
@WilcoFiers @spectranaut @jongund @jnurthen @carmacleod @scottaohara @JAWS-test