-
Notifications
You must be signed in to change notification settings - Fork 125
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.
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
Inconsistent use of "owned by" #1161
Comments
Your explanations do not seem to be right for Better would be: If a required ancestor element has a |
The ARIA Working Group just discussed The full IRC log of that discussion<carmacleod> github: https://github.com//issues/1161<carmacleod> jamesn: waiting on me |
Discussed in 11/12/2020 WG MeetingJN: ok, 1161, inconsistent use of owned by
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) JN: I know you're essentially trying to avoid people having to do 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 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 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 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. 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 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 |
Revisit this after Sarah's PR lands: https://github.com/w3c/aria/pull/1454/files |
#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:
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":
|
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) |
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:
But then if we read
menuitem
, it says the following: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 alist
which is in agrid
which is in aheader
which is in amenu
.And that last part is where I'm starting to have proper concerns. The following seems to be conform to ARIA 1.2:
Even more explicitly, 9.2 basically says that elements are only supposed to have one owned 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):
In this case, it matters that
aria-readonly
propagates to thecell
of agrid
. Although even here it could be argued thataria-readonly
shouldn't propagate down into nestedgrid
elements. That propagation is far more pronounced for thepresentation
role, and here it really matters if "owned elements" is limited to children, or all descendants: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 misplacedrole="presentation"
on thebody
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.
The text was updated successfully, but these errors were encountered: