-
Notifications
You must be signed in to change notification settings - Fork 25
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
Define concept of minimum role #454
base: gh-pages
Are you sure you want to change the base?
Conversation
Worked on this with @aleventhal as this concept is necessary for some current HTML features (as identified in the attribute mapping table in this PR) as well as future proposed features, such as `popover`.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no feedback of substance 😅, just a couple proofing suggestions.
Co-authored-by: Adam Page <adamfpage@gmail.com>
Co-authored-by: Adam Page <adamfpage@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an approval caveat remove the sentence fragment, at least!
Maybe it's time to open issues on the browsers with this change? |
needed to call out that an explicit role of none, presentation or generic would still need to result in that role being ignored if other conditions were true.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see a few problems with this and suggest we schedule a deep dive.
The first is that this doesn't seem to account for native-reserved roles, or roles that we can't yet or haven't yet mimicked with ARIA. For example, <input type="date" autofocus>
or <video tabindex="0">
… I think this change suggests UAs MUST map both to group
, even though it wouldn't be logical to do so. Even if ARIA eventually adds a role for native date pickers, video
is likely to remain separate for a while, because there isn't a good method to support the video API that goes along with it.
The second issue is that ARIA's concept of group requires a much more explicit and purposeful author decision, IMHO, than the related concept in the AX API... As a reminder, AXGroup
predates ARIA's group
by almost a decade, and is used as a generic container. ARIA's group
, as I understand it, represents some explicit logical grouping, so I am not certain it's a good change to force promotion of something like <div contenteditable>
when the author may have added the relevant role and label to another nearby container. E.g.,
<main aria-label="Edit post">
<div contenteditable>
Now I have an extraneous, unlabeled group inside my main, where I hadn't before.
</div>
</main>
Update b/c I thought of another one. Does the sub-span in this one really need a minimum role?
<main contenteditable="true">
Obi-Wan never told you what happened to your father.
He told me enough! He told me you killed him!
<span contenteditable="false">No. I am your father.</span>
</div>
@cookiecrook thank you for the review. per your two comments:
it was definitely the intent to account for that, so happy to incorporate changes to make sure that's included / I'll have a think on other wording to make sure that's clear. re:
that's an interesting idea. Though it makes me think back to past projects I worked on - one being a website builder where there were blocks of editable areas within predefined templates. So a main could have 2 or 3 contenteditable divs within it. Something to think about... |
FYI Our comments crossed when I added a third to the list: |
@cookiecrook we had talked about |
Co-authored-by: James Craig <cookiecrook@users.noreply.github.com>
Co-authored-by: Valerie Young <spectranaut@gmail.com>
adds "not mapped" to the ARIA role cell. there is no perfect role for this right now, and until one is made (if ever) we shouldnt' change this.
We had a deep dive this morning, it seems the main conclusions were:
|
Also that term had been used to describe the fallback roles such as |
We have this ready to land, but I think we should double check with screen reader vendors because it's a big change. It's probably better but I want to be safe. For example, @jcsteh have you looked at it? |
given that |
index.html
Outdated
@@ -5643,7 +5687,9 @@ <h3>HTML Attribute State and Property Mappings</h3> | |||
<td class="uia"><div class="general">Use WAI-ARIA mapping</div></td> | |||
<td class="atk"><div class="general">Use WAI-ARIA mapping</div></td> | |||
<td class="ax"><div class="general">Use WAI-ARIA mapping</div></td> | |||
<td class="comments"></td> | |||
<td class="comments"> | |||
Provides a <a href="termref">minimum role</a> of <a class="core-mapping" href="#role-map-group">`group`</a>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I think we should only do this for tabindex=0. If we do it for tabindex=-1, it might create a lot of noise on web pages where tabindex=-1 is put on random elements for hard-to-explain reasons.
We ran into this when we used to repair missing names on <div tabindex=-1>
by computing the name from contents. It caused too much noise.
index.html
Outdated
@@ -5643,7 +5687,9 @@ <h3>HTML Attribute State and Property Mappings</h3> | |||
<td class="uia"><div class="general">Use WAI-ARIA mapping</div></td> | |||
<td class="atk"><div class="general">Use WAI-ARIA mapping</div></td> | |||
<td class="ax"><div class="general">Use WAI-ARIA mapping</div></td> | |||
<td class="comments"></td> | |||
<td class="comments"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that Hunseop Jeong has implemented this in https://chromium-review.googlesource.com/c/chromium/src/+/4794310 I have questions, because I realize we used to repair nameless occurances of <div tabindex=0>
by computing name from contents. We will no longer be doing this, which could break things like:
<p>I don't know what I'm doing but <div tabindex="0" onclick="clicked()">Click me</div></p>
Should we care about that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Firefox doesn't seem to add name from content to
For JAWS, this change will cause JAWS to announce "group" on focus, but I thihnk that is fine. In addition, if chrome no longer adds name from content to generic elements, the cases where focus moves inside these generic elements with names will be less chatty.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there are kinda two different cases that should be considered here.
a generic element with a tabindex so that it's focusable or in the tab order. those fit under what brett mentioned.
then there are the generic elements with a tabindex which also have a click/some-kind-of event attached. and those are more likely to be things where maybe the name should be calculated to make up for the likely faux buttons being made (not saying they 'should' be buttons. we don't know...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose even without any changes to this PR, the fake <div tabindex=0 onclick>
button will be accessible because the user will be able to read the contents in the virtual buffer. It might not act as nice as a real button, but that's arguably good.
So my next question is whether
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'd still say group. any more than that would make a lot of assumptions that could make the content more difficult to read / could still be wrong in terms of the role. e.g., maybe it's supposed to be a link. maybe it's not really supposed to be either... so stay with group to keep a consistent baseline
Ok, what about in the virtual buffer, e.g. with weird <div tabindex=-1>
cases?
Will those be problematic?
…On Tue, Sep 5, 2023 at 1:00 PM BrettLewisVispero ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In index.html
<#454 (comment)>:
> @@ -5643,7 +5687,9 @@ <h3>HTML Attribute State and Property Mappings</h3>
<td class="uia"><div class="general">Use WAI-ARIA mapping</div></td>
<td class="atk"><div class="general">Use WAI-ARIA mapping</div></td>
<td class="ax"><div class="general">Use WAI-ARIA mapping</div></td>
- <td class="comments"></td>
+ <td class="comments">
Firefox doesn't seem to add name from content to
which matches the ARIA spec regarding generic role. I think having the
behavior match for Chrome and Firefox will be a positive.
For JAWS, this change will cause JAWS to announce "group" on focus, but I
thihnk that is fine. In addition, if chrome no longer adds name from
content to generic elements, the cases where focus moves inside these
generic elements with names will be less chatty.
—
Reply to this email directly, view it on GitHub
<#454 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKQAZVJ4GPSP6YD2YW57QDXY5LCLANCNFSM6AAAAAATW6AGHQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I somehow missed this altogether, so no, i haven't looked at it. I'll endeavour to do so soonish. |
I'm trying to grasp exactly what this gives us that we didn't have before:
|
hi @jcsteh, thanks for giving this a review, and yes, your final point is definitely the crux of this proposal - create consistency in how these and other future / semi-present ( Some more comments related to your other questions:
|
From what I can see, focusing a div produces exactly the same result as focusing a group with NVDA, except that a div reports "section" and a group reports "grouping".
accesskey is interesting in that it is global, but as far as I can tell, it isn't useful if the element to which it is applied is not focusable. Firefox and Chrome both currently expose accesskey on a non-focusable element via accessibility APIs, but pressing the access key does nothing. This raises the question of whether we should be exposing this at all in this case, since it's misleading to the user. Making that decision is probably out of scope here, but it does impact whether we bother having a minimum role in this case. I can't see a benefit given the above.
The problem here is that this assumes either that group is entirely intuitive as a fallback or that it is already being used like this, and I'm not convinced either of these is true. As I noted, unless I'm missing something, group was never really intended to get focus itself, but rather, to be a container for other focusable elements. In that sense, group is no better than generic because in either case, it's not being used for its intended semantic purpose. |
To put this another, more practical way, if a screen reader user tabs to something and just hears "group", they're not going to know what it is. That's no better to the current situation where the user might tab to something and hear just "section", which is also meaningless. Arguably, it's worse because "group" has existing semantic meaning. At least with generic, screen readers could potentially say "unknown element" or something like that, which would signal to the user that the screen reader doesn't have sufficient information about what this is. |
One thing to remember, in Chrome currently, focusable generic elements get their name from content. Group would at least make it clearer that the name must be provided by author.
(of course generic element shouldn’t have names at all).
From: James Teh ***@***.***>
Sent: Thursday, September 21, 2023 10:06 PM
To: w3c/html-aam ***@***.***>
Cc: Brett Lewis ***@***.***>; Comment ***@***.***>
Subject: Re: [w3c/html-aam] Define concept of minimum role (PR #454)
CAUTION: This email originated outside Vispero. Do not click links, open attachments or forward unless you recognize the sender.
To put this another, more practical way, if a screen reader user tabs to something and just hears "group", they're not going to know what it is. That's no better to the current situation where the user might tab to something and hear just "section", which is also meaningless. Arguably, it's worse because "group" has existing semantic meaning. At least with generic, screen readers could potentially say "unknown element" or something like that, which would signal to the user that the screen reader doesn't have sufficient information about what this is.
—
Reply to this email directly, view it on GitHub<#454 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A7R7OJOLNZ6OGOLECSB7YVDX3UMDBANCNFSM6AAAAAATW6AGHQ>.
You are receiving this because you commented.Message ID: ***@***.******@***.***>>
|
had a call with aaron and james today i need to work though if this should be merged, or can be revised into contextual role. i'll work on that soon |
As a new concept called minimum role was added to the HTML-AAM spec[1], and the contents corresponding to global attributes in that spec have been implemented. [1]: w3c/html-aam#454 AX-Relnotes: n/a. Fixed: 1474047 Change-Id: I586506e8ddd1e81ad11e92ef9e167586cb41545e
@scottaohara what's the update on this? Which attributes should we start with? |
OK, finally got back to this and resolved all the merge conflicts. The PR is much simpler to review now in the diff mode. This now adds the minimum role concept, and to start we're indicating this will occur for the
I plan on some editorial revising of this section with the contextual role PR (#484) - but need this to merge first before I work on that anymore. I think this finalizes the outstanding conversations for this PR (with any potential addition of tabindex being it's own topic for the future) |
Still LGTM. |
+1! |
add tests for minimum role in html aam w3c/html-aam#454
Worked on this with @aleventhal as this concept is necessary for some current HTML features (as identified in the attribute mapping table in this PR) as well as future proposed features, such as
popover
.Implementation
Preview | Diff