feat: aria-actions addition to the ARIA spec

[smhigley]

Resolves #1440 by adding the aria-actions attribute

This 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 PR
• Related AccName Issue/PR: feat: update step 2F to exclude nodes referenced by aria-actions accname#235:
• Any other dependent changes?

Test, 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.

• Related APG Issue/PR: Develop tabs example with actions on each tab using aria-actions property aria-practices#3070, Add experimental example of tabs with action buttons to demonstrate aria-actions aria-practices#3071
• MDN Issue/PR:
• "author MUST" tests:
• "user agent MUST" tests
• Browser implementations (link to issue or when done, link to commit):
  • WebKit:
  • Gecko:
  • Blink:
• Does this need AT implementations? - yes
• add IDL mapping, per this comment

---

Preview | Diff

[cookiecrook]

@aleventhal @jcsteh @mcking65

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.

[cookiecrook]

@smhigley I updated the property description to move this along. Nearly ready IMO. Some comments in the diff.

[mcking65]

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.

[mcking65]

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:

Suggested change

	<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>

[cookiecrook]

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?

[mcking65]

I propose the following to:

1. remove other potentially confusing uses of the term "current element".
2. Provide more clarity about the benefits and expected assistive technology support.

Suggested change

	<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>

[cookiecrook]

Removing this line reduces the clarity. Why? Both types look identical to a web author.

-  or by simulated pointer events from assistive technology.

[cookiecrook]

Modifying Matt's prose to keep the first "sim event" reference and other ARIA editorial conventions like s/property/attribute/

Suggested change

	<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>

[mcking65]

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.

Suggested change

	<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>

[cookiecrook]

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.

[cookiecrook]

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.

[mcking65]

@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.

[aleventhal]

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.

[smhigley]

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.

[mcking65]

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:

1. Require one of the following to be true about the element with aria-actions:
   1. It is focusable
   2. It is referenced by aria-activedescendant from a focusable element
   3. It is inside of an editor (not sure how to spec this yet)
2. User agents do not expose the actions in the accessibility API unless one of the following is true:
   1. The element has DOM focus
   2. aria-activedescendant is referring to it from an element with DOM focus
   3. The element is inside an editor that has focus

[aleventhal]

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.

[cookiecrook]

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 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.

[cookiecrook]

I wonder if it would be possible to have requirements that:

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.

[lukewarlow]

Are there any open questions with this functionality that needs any help?

[MrHBS]

What else is needed to get this PR merged?

[cookiecrook]

@MrHBS wrote:

What else is needed to get this PR merged?

• @smhigley If there are no more queued changes in your to-do list or major updates since my review, you could mark the draft PR as ready for review.
• Then we need a second reviewer to approve.
• We can't write automated WPT tests for this yet, but we could also use some manual test cases the implementors could develop against.
• Then we need linked tracking issues in each of the 3 major engines.
• Once two engines have implemented the feature, then the PR can be merged.

[netlify]

✅ Deploy Preview for wai-aria ready!

Name	Link
🔨 Latest commit	3b9b4b8
🔍 Latest deploy log	https://app.netlify.com/sites/wai-aria/deploys/66f1b8597dcccf00087166ba
😎 Deploy Preview	https://deploy-preview-1805--wai-aria.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[jcsteh]

Thanks for working on this.

[jcsteh]

UIA doesn't have object attributes. Perhaps you meant this?

Suggested change

	<span class="property">Object Attribute: <code>aria-actions</code> &lt;value&gt;</span>
	<span class="property">Property: <code>AriaProperties.actions</code>: &lt;value&gt;</span>

That said, I don't quite follow why we're exposing this. See above.

[smhigley]

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.

[smhigley]

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 😅

[aleventhal]

Do we definitely need to expose the fact that actions exist when they aren't currently rendered?

[MarioBatusic]

I don't think so. What can a screen reader user begin with emty actions?

[jcsteh]

Why do we want to expose this? We don't normally expose idrefs in object attributes. IAccessibleAction should be sufficient.

[jcsteh]

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.

[smhigley]

tagging in @cookiecrook for this one, since he wrote the wording for it 😊

[rahimabdi]

Hi @smhigley: should aria-actions be included in the ARIAMixin IDL block? i.e.,

[CEReactions] attribute FrozenArray<Element>? ariaActionsElements;

[smhigley]

Consolidating to-dos from the TPAC discussion:

• Add wording about respecting the order of actions defined as the order of ids (clarify in both ARIA and Core AAM)
• change dialog/close example to video player example or code block copy example (or both)
• clarify that elements supporting actions must be keyboard focusable & receive keyboard focus when actions are relevant
• update the authors should > authors must for actions existing in the DOM when the referencing element is focused

[aleventhal]

• clarify that elements supporting actions must be keyboard focusable & receive keyboard focus when actions are relevant

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.

[smhigley]

@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 aria-actions (so no querying of elements by id, only reflecting the string value) when the referencing element does not have a11y focus, and only doing the full IAccessibleActions mapping when in focus?

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. aria-actions="" or aria-actions="id-that-doesnt-exist" will reliably provide valid actions when the element in question has focus. I also think there isn't really precedence for assigning that sort of meaning to an empty string value (or list of invalid id references).

[smhigley]

Hi @smhigley: should aria-actions be included in the ARIAMixin IDL block? i.e.,

[CEReactions] attribute FrozenArray<Element>? ariaActionsElements;

@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?

[css-meeting-bot]

The ARIA Working Group just discussed AT expectations for aria-actions.

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?

[rahimabdi]

@smhigley Not pressing IMO but thanks for the follow-up!

[smhigley]

@rahimabdi I've added a task to the PR description for it :)