feat: aria-actions addition to the ARIA spec #1805
Conversation
cookiecrook
requested review from
cookiecrook,
mcking65,
aleventhal and
jcsteh
|
Adding reviewers to get some more perspectives on this. The description is missing in the PR, but the relevant discussion is in #1440, and I think the idea is sound. |
|
@smhigley I updated the property description to move this along. Nearly ready IMO. Some comments in the diff. |
There was a problem hiding this comment.
I think we need a discussion of whether aria-actions should be allowed on elements that are not focusable or referenced by aria-activedescendant. I see potentially big problems with elements that are containers with boundaries that screen readers treat as invisible. I also am concerned about the idea that it could be used on a dialog, which by default, should not be focusable; that is only a fall-back error condition where a dialog would get focus.
I have added several suggestions where I think the language needs more clarity.
index.html
Outdated
| <div class="property" id="aria-actions"> | ||
| <pdef>aria-actions</pdef> | ||
| <div class="property-description"> | ||
| <p><a>Identifies</a> a related element or elements whose primary activation (<code>click</code> event) will trigger a behavior or operation relevant to the referencing user interface object, such as the close button for a dialog, or a reply button relevant to the specific email message in focus.</p> |
There was a problem hiding this comment.
I propose we remove the phrase indicating that aria-actions would be used to associate a dialog element to its close button. We need discussion about that specific use case. I think that is a potentially problematic idea.
If the property definition is going to include a phrase that starts with "such as" or "for example", I propose that such a phrase be more clear and concise.
Here's my suggestion:
| <p><a>Identifies</a> a related element or elements whose primary activation (<code>click</code> event) will trigger a behavior or operation relevant to the referencing user interface object, such as the close button for a dialog, or a reply button relevant to the specific email message in focus.</p> | |
| <p><a>Identifies</a> a related element or elements whose primary activation (<code>click</code> event) will trigger a behavior or operation relevant to the referencing user interface object, e.g., identifies the button that generates a reply to the focused message in an email inbox.</p> |
There was a problem hiding this comment.
I propose we remove the phrase indicating that aria-actions would be used to associate a dialog element to its close button. We need discussion about that specific use case. I think that is a potentially problematic idea.
What is problematic about it? Users should be able to close a dialog by pressing the escape key (or platform-specific dismiss trigger like VO's scrub), or navigating to a activating the close button, so what's wrong with another way to trigger that?
index.html
Outdated
| <pdef>aria-actions</pdef> | ||
| <div class="property-description"> | ||
| <p><a>Identifies</a> a related element or elements whose primary activation (<code>click</code> event) will trigger a behavior or operation relevant to the referencing user interface object, such as the close button for a dialog, or a reply button relevant to the specific email message in focus.</p> | ||
| <p>The <code>aria-actions</code> attribute allows an element to reference other interactive elements which trigger actions on the current element. For example, in a web mail application, the currently selected email message may reference action elements such as the <em>message-specific</em> Reply, Forward, and Delete buttons. Actions are triggered by mainstream pointer events (click, tap) or by simulated pointer events from assistive technology.</p> |
There was a problem hiding this comment.
I propose the following to:
- remove other potentially confusing uses of the term "current element".
- Provide more clarity about the benefits and expected assistive technology support.
| <p>The <code>aria-actions</code> attribute allows an element to reference other interactive elements which trigger actions on the current element. For example, in a web mail application, the currently selected email message may reference action elements such as the <em>message-specific</em> Reply, Forward, and Delete buttons. Actions are triggered by mainstream pointer events (click, tap) or by simulated pointer events from assistive technology.</p> | |
| <p>The <code>aria-actions</code> attribute allows an element to reference other interactive elements that trigger actions related to the referencing element. For example, in the inbox of a web mail application, the element that represents the currently focused or selected email message may reference action elements such as the <em>message-specific</em> Reply, Forward, and Delete buttons. Actions are triggered by mainstream pointer events (click, tap).</p> | |
| <p>This property enables assistive technologies to simulate pointer events that trigger the actions without requiring users to move focus to the element that triggers the action. That is, in the email inbox example, a screen reader could enable users to delete the currently focused message in the inbox without having to find and press the delete button.</p> |
There was a problem hiding this comment.
Removing this line reduces the clarity. Why? Both types look identical to a web author.
- or by simulated pointer events from assistive technology.There was a problem hiding this comment.
Modifying Matt's prose to keep the first "sim event" reference and other ARIA editorial conventions like s/property/attribute/
| <p>The <code>aria-actions</code> attribute allows an element to reference other interactive elements which trigger actions on the current element. For example, in a web mail application, the currently selected email message may reference action elements such as the <em>message-specific</em> Reply, Forward, and Delete buttons. Actions are triggered by mainstream pointer events (click, tap) or by simulated pointer events from assistive technology.</p> | |
| <p>The <code>aria-actions</code> attribute allows an element to reference other interactive elements that trigger actions related to the referencing element. For example, in the inbox of a web mail application, the element that represents the currently focused or selected email message may reference action elements such as the <em>message-specific</em> Reply, Forward, and Delete buttons. Actions are triggered by mainstream pointer events (click, tap) or by simulated pointer events from assistive technology.</p> | |
| <p>This attribute enables assistive technologies to simulate clicks or taps that trigger the actions without requiring users to move focus to the element that triggers the action. For example, when using a web mail application, a screen reader action could enable users to quickly delete or reply to the currently focused message, without having to navigate to and press the relevant button.</p> |
| <li>Authors MUST ensure that related action elements have a label.</li> | ||
| <li>Authors MUST ensure that related action elements accept a <code>click</code> event handler or default activation behavior.</li> | ||
| <li>Authors MUST ensure that related action events are not limited to a modality-specific activation such as the <code>keyup</code> or <code>touchend</code> event handlers.</li> | ||
| <li>Authors SHOULD ensure that related actions elements are visible and activatable when the current element is focused by the user agent or assistive technology.</li> |
There was a problem hiding this comment.
Why is this a "SHOULD" instead of a "MUST"?
The "focus" aspect of this requirement should specifically address active descendant in a way that is consistent with how we do so elsewhere.
| <li>Authors SHOULD ensure that related actions elements are visible and activatable when the current element is focused by the user agent or assistive technology.</li> | |
| <li>Authors SHOULD ensure that elements referenced by <code>aria-actions</code> are visible and activatable when the referencing element is focused or when the referencing element is referenced by <sref>aria-activedescendant</sref> from an element that has DOM focus.</li> |
There was a problem hiding this comment.
Why is this a "SHOULD" instead of a "MUST"?
Mainly because an author cannot detect all forms of AT focus, so there is no way to achieve a MUST. But also to avoid overly restrictive UI flexibility. Authors may have good reasons for not doing this, so we should not penalize them with a validation error.
Since you addressed the active descendant in a later thread, let's continue that discussion there.
There was a problem hiding this comment.
Re: Matt's suggestion of
+ or when the referencing element is referenced by <sref>aria-activedescendant</sref> from an element that has DOM focus.IMO, this change will reduce the clarity of the intention and complicate the implementation... In this scenario, it's okay for the container element to manage these actions rather than the activedescendant. Chaining an action through an activedescendant has no precedence on any platform I'm aware of.
There was a problem hiding this comment.
@cookiecrook wrote:
Mainly because an author cannot detect all forms of AT focus, so there is no way to achieve a MUST. But also to avoid overly restrictive UI flexibility.
Authors should not be able to detect the presence of AT or any form of AT focus. I think we should remove the phrase "focused by assistive technology" from the definition. AFAIK, we have not defined assistive technology focus and do not use it elsewhere in the spec.
I don't quite understand how this would work without mapping actions to elements referenced by aria-activedescendant. Consider a listbox or tree implemented with aria-activedescendant. If there is going to be a custom action on each option or treeitem, the option or treeitem will not have DOM focus; it will be referenced by aria-activedescendant.
There was a problem hiding this comment.
Why is this a "SHOULD" instead of a "MUST"?
Mainly because an author cannot detect all forms of AT focus, so there is no way to achieve a MUST. But also to avoid overly restrictive UI flexibility. Authors may have good reasons for not doing this, so we should not penalize them with a validation error.
I think there are some potential author musts here.
If the focus is from the UA, then any aria-actions must be visible.
In fact, if the element with aria-actions is visible, then all of it's aria-actions elements must also be visible.
There was a problem hiding this comment.
Would folks generally be in favor of removing "or assistive technology" and make it a "MUST", making the entire sentence read as follows?:
Authors MUST ensure that related actions elements are visible and activatable when the current element is focused by the user agent.
|
To what extent is avoiding creating additional vectors for the active finger printing mentioned in section 11 a consideration in the design of this feature? I see some language that appears to be aimed in that direction, such as the requirement for using clicks and default actions. However, as written, it appears to me that it is all author responsibility, and is thus a wide open door. I wonder if it would be possible to have requirements that:
|
|
Matt, why do we need the focusable rule? Would it not be enough for the source to be visible, and the target to be visible & clickable? To activate the action, the browser can send it a click as if a real mouse click occurred. |
I think you may misunderstand. If an author doesn't use a click, it won't reveal anything new about the user. The UI just may not work in some scenarios. We purposefully limited AT's trigger-ability here to a click (rather than a new event or direct API call) to avoid risk of detection. |
Those are all much too rigid/restrictive in my opinion. And possibly too screenreader specific. AT focus or focus-in is an expectation, but not DOM focus. Otherwise we may not be able to make this work well for other AT like Switch Control, Voice Control, etc. Likewise Dragon on Windows, Android's Switch Access, etc. |
|
Are there any open questions with this functionality that needs any help? |
|
What else is needed to get this PR merged? |
|
@MrHBS wrote:
|
Co-authored-by: Matt King <a11yThinker@Gmail.com>
Co-authored-by: Matt King <a11yThinker@Gmail.com>
smhigley
force-pushed
the
secondary-actions
branch
from
030ea0f
to
84667d3
Compare
✅ Deploy Preview for wai-aria ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
core-aam/index.html
Outdated
| <span class="property" | ||
| >Custom Property: <code>AccessibleActions</code>: element array of accessible nodes matching IDREFs, if the referenced objects are in the accessibility tree</span | ||
| ><br /> | ||
| <span class="property">Object Attribute: <code>aria-actions</code> <value></span> |
There was a problem hiding this comment.
UIA doesn't have object attributes. Perhaps you meant this?
| <span class="property">Object Attribute: <code>aria-actions</code> <value></span> | |
| <span class="property">Property: <code>AriaProperties.actions</code>: <value></span> |
That said, I don't quite follow why we're exposing this. See above.
There was a problem hiding this comment.
Ah yup, I meant to do Property: AriaProperties.actions: <value>, thanks for catching that!
It came up in discussions with NVDA & JAWS -- it's definitely not as important as the IAccessibleActions pattern or the AccessibleActions custom property, but folks on those calls said it could be useful as a quick way to check if actions are intended to exist for a given node.
I'm not super opinionated on this one, and we can bring it up again to ask if it's needed.
There was a problem hiding this comment.
In conversations today I remembered another reason for this -- it should in theory allow for the possibility to query whether an element has actions even when those actions are not present in the DOM.
I think the issue with that approach is that authors also might not pass in id values when the elements they refer to are not rendered. I'm now wondering if we should treat the presence of the aria-actions attribute, even if set to the empty string, as meaningful or indicative of an element supporting actions even if they are not currently rendered.
WDYT? In theory perhaps the interface mapping with an empty array could also indicate that, and maybe this whole idea is too over-engineered 😅
There was a problem hiding this comment.
Do we definitely need to expose the fact that actions exist when they aren't currently rendered?
There was a problem hiding this comment.
I don't think so. What can a screen reader user begin with emty actions?
There was a problem hiding this comment.
@MarioBatusic the idea is that the actions will exist when the control gains focus (or hover, usually), but may not exist before then. If a screen reader user is browsing with virtual cursor and doesn't have focus following the cursor, this mapping would make it possible to still let them know that actions exist. If they attempt to interact with those actions, the screen reader would focus on the control, thus presumably causing the actions to render.
There was a problem hiding this comment.
@jcsteh I updated the mapping to be an empty string rather than the value, as we discussed at TPAC. WDYT?
Also if anyone's opinions change on whether this is a valuable thing to have, let me know. I'm still a bit ambivalent (mostly worried that aria-actions with invalid ids will still get exposed, but nothing will show up even after focusing the control)
core-aam/index.html
Outdated
| <span class="property" | ||
| >Interface: <code>IAccessibleAction</code>, using the accessible nodes matching `aria-actions` IDREFs, if the referenced objects are in the accessibility tree</span | ||
| ><br /> | ||
| <span class="property">Object Attribute: <code>aria-actions</code> <value></span> |
There was a problem hiding this comment.
Why do we want to expose this? We don't normally expose idrefs in object attributes. IAccessibleAction should be sufficient.
| <tr> | ||
| <th><abbr title="macOS Accessibility Protocol">AX API</abbr></th> | ||
| <td> | ||
| <span class="property">Implement as <a href="https://developer.apple.com/documentation/uikit/uiaccessibilitycustomaction">custom action</a></span> |
There was a problem hiding this comment.
As I understand it, UIAccessibilityCustomAction (as linked here) can only be used with Mac Catalyst. Browsers aren't Mac Catalyst apps, so I don't think they can use this. We need the equivalent for the protocol used by Mac desktop apps.
There was a problem hiding this comment.
tagging in @cookiecrook for this one, since he wrote the wording for it 😊
|
Hi @smhigley: should
|
|
Consolidating to-dos from the TPAC discussion:
|
Does this mean that the browser must only expose the actions when the object has a11y focus? (via DOM focus or activedescendant). This certainly would make things simpler, because "focusable" is actually not a perfect signal, since we don't know which elements with ids are potentially going to be active descendants. We make good guesses but it's not deterministic. E.g. in Chromium (not sure about others) we expose an element with an id as focusable if it also has a role attribute (not just inherited role from HTML) and an ancestor with the aria-activedescendant attribute present. |
|
@aleventhal either your timing was serendipitous, or you saw my comment here :D Would it make sense to expose only the mapping for object attributes of The use case would be the use cases discussed when a screen reader may want to query either an ancestor of the currently focused element for actions in very specific cases (e.g. in a video player), or want to look at whether actions exist when an element has virtual cursor focus but not keyboard focus. The referencing element would need to be given keyboard focus in order to actually expose the menu of actions, but in theory it might be helpful to know whether an element potentially has actions before giving it focus. I think my worry with that is that it may not be possible in practice to trust that authors who coded e.g. |
@rahimabdi Thanks for catching this! That type looks right to me, is that something that should be done now, or when this is closer to being ready to merge? |
|
The ARIA Working Group just discussed The full IRC log of that discussion<ZoeBijl> topic: AT expectations for aria-actions<sarah> https://gist.github.com/smhigley/37180c2ba6ba86bd2e1dba6e1a4de464 <ZoeBijl> MK: the beginning part of Sarah’s gist is what we were talking about yesterday <ZoeBijl> one of the things that we want to align around is that there are essentially two high level expections <ZoeBijl> s/expections/expectations/ <ZoeBijl> sarah: the first part is browser requirements <ZoeBijl> [talking about authoring requirements <ZoeBijl> s/requirements/requirements]/ <ZoeBijl> there are two levels of screen reader support <ZoeBijl> the most basic one which is a must would be announcing the availability of actions <ZoeBijl> if you have like list of email where each email has “flag”, “read”, “other” <ZoeBijl> you wouldn’t list all of those actions for each item <ZoeBijl> it won’t read those names <ZoeBijl> that would be very repetitive <ZoeBijl> so screen readers should announce that actions exist <ZoeBijl> using whichever wording they desire <ZoeBijl> the second requirement is the announcing the number of actions <ZoeBijl> any interactive element with actions defined, there should be a way to pull up these actions <ZoeBijl> perhaps in a menu <Brett-Lewis> Q+ <ZoeBijl> getting the actions’ accessible names <ZoeBijl> and there’s a few markup examples in the gist <ZoeBijl> for that list of emails: <ZoeBijl> https://www.irccloud.com/pastebin/q6FwVbgA/ <ZoeBijl> if a user would press that menu they could choose from the actions <ZoeBijl> all the while focus would remain on the email <ZoeBijl> i have two open questions <ZoeBijl> 1. Should screen readers sometimes expose actions defined on ancestor elements when focusing child elements? <ZoeBijl> 2. Can nodes focused with aria-activedescendant support actions defined on them? <ZoeBijl> MK: on the first one i want to add <ZoeBijl> yesterday we talked <ZoeBijl> so however <ZoeBijl> that makes this first question really important <ZoeBijl> let’s imagine that you have an article in a feed or a cell in a grid <ZoeBijl> and the screen reader user is reading inside this article or cell <ZoeBijl> and int he cotnainer that item <ZoeBijl> s/int he cotnainer/in the container/ <jcraig> q+ to mention iOS VoiceOver's current ways to convey actions are a multiple select list of: speak, play sound, change pitch, braille, or do nothing." there are some additional options too. Default is speak + braille. <ZoeBijl> but the user is reading content inside the container <ZoeBijl> would that sr user’s reading cursor, on the decending node <ZoeBijl> should the sr <ZoeBijl> read up the tree and find out if the nearest ancestor has actions? <jamesn> ack Brett-Lewis <ZoeBijl> we should define that algoritm if anything, clearly <ZoeBijl> Brett-Lewis: i have a couple things <ZoeBijl> announcing actions would only happen on focus? <ZoeBijl> sarah: yes <ZoeBijl> Brett-Lewis: if i’m in the buffer and i encounter a button <ZoeBijl> if i want the actions <ZoeBijl> i have to move up the tree to focus that ancestor with actions <ZoeBijl> that way you can announce there are actions <ZoeBijl> maybe an unanticipated consequence <ZoeBijl> the disconnect between the virtual buffer and the focus <sarah> q+ <ZoeBijl> glad you brought it up Matt <aaronlev> q+ <ZoeBijl> MK: you think that’s… <ZoeBijl> i mean if you were reading a big article <ZoeBijl> and in the middle <ZoeBijl> you want to report it the post <ZoeBijl> do you think it would be bad if you could report and then jumped back to where you were <ZoeBijl> Brett-Lewis: but what if you don’t activate the action <ZoeBijl> MK: i think you can program around that because you’re very smart! <jcraig> q+ to suggest :focus-within https://developer.mozilla.org/en-US/docs/Web/CSS/:focus-within <ZoeBijl> [laughter] <ZoeBijl> you could remember where focus was <ZoeBijl> Brett-Lewis: that’s harder to do <ZoeBijl> Jamie: the triggering element should still exist <ZoeBijl> jcraig: maybe we digress <jcraig> ack me <Zakim> jcraig, you wanted to mention iOS VoiceOver's current ways to convey actions are a multiple select list of: speak, play sound, change pitch, braille, or do nothing." there are some <Zakim> ... additional options too. Default is speak + braille. and to suggest :focus-within https://developer.mozilla.org/en-US/docs/Web/CSS/:focus-within <ZoeBijl> quick add-in <ZoeBijl> great points made <ZoeBijl> maybe what we could do and say is equivelant to css’ focus-within <ZoeBijl> so maybe not focus on the ancestor <ZoeBijl> but also when focus within the ancestor <ZoeBijl> by default voiceover on ios <ZoeBijl> will say “actions available” <ZoeBijl> also in braille <ZoeBijl> and the features available now <ZoeBijl> you can speak it <ZoeBijl> you can play a sound <ZoeBijl> adjust the label of the focusable <ZoeBijl> or braille it <ZoeBijl> or do nothing <ZoeBijl> those are examples <ZoeBijl> thank you for phrasing it in this way <alice> q+ to ask about name computation <spectranaut_> ack sarah <ZoeBijl> sarah: i can add “play a sound” etc to our list potential approached <ZoeBijl> when you’re inside the referencing element <ZoeBijl> i would be more inclined to drop that for now <ZoeBijl> to not overcomplicate things for now <ZoeBijl> because it’s quite specific in scope <ZoeBijl> like video players <ZoeBijl> or being in cells <ZoeBijl> just because i don’t want to overcomplicate things <ZoeBijl> the focus-within thing is interesting <ZoeBijl> but it might conflict with things like aria-owns <ZoeBijl> i don’t know if i want to touch that <ZoeBijl> jcraig: focus-within wouldn’t work with an aria-owns relationship <ZoeBijl> MK: you could be reading inside ??? <spectranaut_> ack aaronlev <ZoeBijl> sarah: and i don’t, i lean towards not making specs more complicating than that <Jamie> s/???/a grid cell when the grid doesn't even have focus <ZoeBijl> aaronlev: so what i want to understand is that the brower engine would only have to expose ??? <ZoeBijl> which would make things easier to implement <ZoeBijl> sarah: Jamie had ?? <ZoeBijl> if you want to share that with me <spectranaut_> s/???/aria-actions on the focused node/ <ZoeBijl> Jamie: yea <aaronlev> q- <ZoeBijl> sarah: i have two mappings <ZoeBijl> ?? <ZoeBijl> and the object attributes <ZoeBijl> that bucket of attributes <ZoeBijl> i put it in both <ZoeBijl> because jamie asked me if it was enough <ZoeBijl> github: https://github.com//pull/1805 <smockle> q? <ZoeBijl> ???? <ZoeBijl> aaronlev: how much value is there to the user for not exposing actions ont he ?? <smockle> q+ <ZoeBijl> MK: sarah and i talked about <ZoeBijl> making aria-actions “usable” <ZoeBijl> we’re not providing those relations until this thing is focusable <ZoeBijl> aaronlev: i’m ok with that <ZoeBijl> to indicate that actions are available <ZoeBijl> make sure there’s targetable ?? <ZoeBijl> Jamie: it will be complicated with ??? <ZoeBijl> jcraig: i think it’ll be ok <ZoeBijl> Jamie: if those elements are ?? <ZoeBijl> then you into a whole bunch of problems <ZoeBijl> if the elements don’t have ids <ZoeBijl> alice: quote quote means that you set it via the idl? <ZoeBijl> from the browser side you have to check the ??? <ZoeBijl> you have to check that nowhere in you’re ?? <ZoeBijl> Jamie: it means that no where in your code you @@ <ZoeBijl> jcraig: but does it matter? <ZoeBijl> the only time it differs when you’re not focused on it anyway <ZoeBijl> Jamie: haha, i’m possibly agreeing <ZoeBijl> MK: if it’s not resolved <jcraig> q+ <ZoeBijl> but if it’s focused and not resolved ?? <spectranaut_> ack alice <Zakim> alice, you wanted to ask about name computation <ZoeBijl> alice: jamie commented he was also thinking about this <ZoeBijl> i was curious about your example <ZoeBijl> you have the tree item with all the buttons <ZoeBijl> how does that affect accname <ZoeBijl> sarah: there’s a pr against accname <ZoeBijl> which i made separate because of performance considerations <ZoeBijl> ack alice <spectranaut_> ack smockle <ZoeBijl> smockle: about focus within <sarah> accName aria-actions PR: https://github.com//pull/2208 <ZoeBijl> would that bring back ?? <ZoeBijl> jcraig: i can explain <ZoeBijl> ack jcraig <spectranaut_> ack jcraig <ZoeBijl> i keep hearing people say that <alice> s/??/inherited actions/ <ZoeBijl> i was never of the opionion that we resolved inherited actions? <ZoeBijl> like scroll-grou-button <Jem> Thanks for working on aria - actions, @sarah! I think this can solve one problem I faced with the Medicaid app by the state of Illinois. <ZoeBijl> i believe we want those actions to work <ZoeBijl> likewise we want actions to work even when you’re inside a table row <ZoeBijl> i think focus-within could be a way to achieve that <ZoeBijl> maybe not with unlimited scope <ZoeBijl> but to an certain level up the tree <spectranaut_> q? <ZoeBijl> MK: when i said that i thought it was resolved <ZoeBijl> i thought we said that it would be authors responsibility <ZoeBijl> like they would have to put it where the actions are exposed <ZoeBijl> this means it doesn’t have to be on everything <ZoeBijl> we can avoid some unusual and hard to understand example <ZoeBijl> so in voice memos <ZoeBijl> in ios <ZoeBijl> there’s a set of actions on the voice memo <ZoeBijl> like play/pause/delete etc <ZoeBijl> when i’m focused ont he delete button there’s an action to delete <ZoeBijl> am i deleting the delete button? <ZoeBijl> same thing in the ios mail app <ZoeBijl> Jamie: yea if you’re on a message <ZoeBijl> there’s a reply action <ZoeBijl> MK: yea those links inside the email have actions too <smockle> s/smockle: about focus within/smockle: if every element with `:focus-within` had its actions exposed, then wouldn’t that bring back inherited actions, which we’d decided against yesterday? <ZoeBijl> like are you copying the link or the whole email? <Jem> is it about "scope of action" discussion? <ZoeBijl> jcraig: you can also look at it from the opposite perspective <ZoeBijl> anything with actions it can inherit those from parents <ZoeBijl> you could aria-actions="" to overwrite this? <ZoeBijl> essentially unsetting <ZoeBijl> jamie: maybe it has actions though <ZoeBijl> but you don’t want the inherited ones <ZoeBijl> jcraig: yea i’m not saying you want to combine the element’s actions with those of its parents <jamesn> q? <sarah> q? <Brett-Lewis> q+ <ZoeBijl> so if a td has it’s own actions it wouldn’t inherit actions from the row <ZoeBijl> the author tedium i’m trying to avoid <Jem> q+ to ask what is next step for this proposal <ZoeBijl> is that the author will have to put those actions on each element <sarah> q? <sarah> q+ <ZoeBijl> i’m saying that if you can null it out on items that you don’t want to have actions it would save a lot of hassle/code <smockle> q+ <ZoeBijl> Jamie: feels like a follow up item <sarah> aria-actions="lol nope" < special cased <smockle> q- <jamesn> zakim, close the queue <Zakim> ok, jamesn, the speaker queue is closed <ZoeBijl> Brett-Lewis: if you inherit all these actions <ZoeBijl> say you’re in a td <ZoeBijl> and you inherit the actiosn from the table <ZoeBijl> that would effect the focus <ZoeBijl> jcraig: is that an implementation detail of jaws? <ZoeBijl> Brett-Lewis: no not at all <ZoeBijl> ??? <ZoeBijl> jcraig: that’s why i suggested focus-within <ZoeBijl> Brett-Lewis: even with focus-within @@ <ZoeBijl> i now have to move focus to within that container <ZoeBijl> jcraig: to clarify this is an artifact of the virtual buffer <jamesn> q? <ZoeBijl> jamie: it would be the same in voiceover if you didn’t have the focus tracking <jamesn> ack Brett-Lewis <ZoeBijl> MK: can a sr make the current element focus the element? <ZoeBijl> can you make the sr change focus? <jamesn> ack Jem <Zakim> Jem, you wanted to ask what is next step for this proposal <ZoeBijl> jcraig: only if the element is focusable <ZoeBijl> voiceover is not going to modify the dom to do tha <ZoeBijl> s/tha/that/ <jamesn> ack sarah <ZoeBijl> sarah: i still propose we drop the inherited stuff for now <ZoeBijl> with some exceptions such as ?? <ZoeBijl> i think we don’t have enough information on how people are going to use this for now <alice> s/??/browser-native UI like selectmenu?/ <Jem> +1 for making things be simple for now to explore further. <ZoeBijl> i’ll try to formalise the stuff that’s in the gist <ZoeBijl> maybe we can convince the chrome? people to implement this <ZoeBijl> jamesn: step 2.7 right? <jamesn> zakim, open the queue <Zakim> ok, jamesn, the speaker queue is open <ZoeBijl> [haha yes] <jamesn> q? |
|
@smhigley Not pressing IMO but thanks for the follow-up! |
|
@rahimabdi I've added a task to the PR description for it :) |
|
I think there are some edge cases that haven't been discussed yet. What should we do if
|
| <li>Authors MUST ensure that related action elements respond to a <code>click</code> event and are not limited to modality-specific activation such as the <code>keyup</code> or <code>touchend</code> events.</li> | ||
| <li>Authors MUST ensure each referenced action element is either directly navigable with the keyboard or that there is a keyboard shortcut to directly activate it when focus is on the referencing element.</li> | ||
| <li>Authors SHOULD ensure that related actions elements are visible and activatable when the current element is focused by the user agent or assistive technology.</li> | ||
| <li>User Agents SHOULD use the accessible names of elements referenced by <code>aria-actions</code> to determine the names of actions that are exposed in a platform accessibility API.</li> |
There was a problem hiding this comment.
Should we have some "User Agents MUST"s here? Aaron and I were thinking something along the lines of "User Agents must not expose aria-actions if the Author MUSTs are not followed".
There was a problem hiding this comment.
Oh yeah, I can see why that would be helpful. Do you have suggestions for specific exceptions? The first one that comes to mind is not exposing actions if the element is in focus, but the action ids do not point to an element.
Great questions! I'll go in order:
|
| <li>`doAction`: behave as if `doAction(0)` were called on the corresponding target accessible node.</li> | ||
| </ul> </span | ||
| ><br /> | ||
| <span class="property">Object Attribute: <code>aria-actions: ""</code></span> |
There was a problem hiding this comment.
I suggest has-actions: true
- In the future, the actions could come from HTML
- We don't typically name object attributes using "aria" in the name because at that point as the semantics should be technology-agnostic where possible
- The pattern typically has a value, often "true".
@jcsteh WDYT?
There was a problem hiding this comment.
makes sense to me, FWIW. But yeah, I think @jcsteh's sign-off is more important :D
Agree with Sarah here... Example could be that aria-actions points to a single delete button for the collection view while you're selected on any (or multiple) items in the collection.
We discussed this pretty extensively for the author requirement... In order to effectively obfuscate whether the even is being synthesized by AT (Web Design Principle §2.9) the even needs to track as a standard mainstream event, in this case a pointer click. So the author expectation is to make these rendered if not fully visible. We have not discussed UA requirements, other than to obfuscate whether the click is really pointer driven or synthesized. I would not expect a click event to fire on an unrendered element, but I think it's harmless to have the click come in on a rendered-but-invisible element like a button set to Great point that this should be agreed upon language in the spec.
I recall we discussed |
Resolves #1440 by adding the
aria-actionsattributeThis has a dependency on the changes in #1454.
PR tracking
Check these when the relevant issue or PR has been made, OR after you have confirmed the
related change is not necessary (add N/A). Leave unchecked if you are unsure. Read the
Process Document or
Test Overview for more information.
Related Core AAM Issue/PR: included in this PRTest, Documentation and Implementation tracking
Once this PR and all related PRs have been been approved by the working group, tests
should be written and issues should be opened on browsers. Add N/A and check when not
applicable.
Preview | Diff