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.

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

feat: aria-actions addition to the ARIA spec #1805

Open
wants to merge 19 commits into
base: main
Choose a base branch
from
Open

Conversation

smhigley
Copy link
Contributor

@smhigley smhigley commented Sep 16, 2022

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.

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.


Preview | Diff

@cookiecrook
Copy link
Contributor

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

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

index.html Outdated Show resolved Hide resolved
index.html Outdated Show resolved Hide resolved
index.html Outdated Show resolved Hide resolved
index.html Outdated Show resolved Hide resolved
index.html Outdated Show resolved Hide resolved
index.html Outdated Show resolved Hide resolved
index.html Outdated Show resolved Hide resolved
Copy link
Contributor

@mcking65 mcking65 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

-  or by simulated pointer events from assistive technology.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>

index.html Outdated Show resolved Hide resolved
index.html Outdated Show resolved Hide resolved
index.html Outdated Show resolved Hide resolved
<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>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

index.html Outdated Show resolved Hide resolved
@mcking65
Copy link
Contributor

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

aleventhal commented Feb 10, 2023

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

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

cookiecrook commented Feb 10, 2023

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
Copy link
Member

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

@MrHBS
Copy link

MrHBS commented Apr 6, 2024

What else is needed to get this PR merged?

@cookiecrook
Copy link
Contributor

cookiecrook commented Apr 19, 2024

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

Copy link

netlify bot commented Sep 11, 2024

Deploy Preview for wai-aria ready!

Name Link
🔨 Latest commit 9d0397f
🔍 Latest deploy log https://app.netlify.com/sites/wai-aria/deploys/67200239bee54d0008f6c04e
😎 Deploy Preview https://deploy-preview-1805--wai-aria.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

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

index.html Outdated Show resolved Hide resolved
core-aam/index.html Outdated Show resolved Hide resolved
Copy link

@jcsteh jcsteh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this.

core-aam/index.html Outdated Show resolved Hide resolved
core-aam/index.html Outdated Show resolved Hide resolved
core-aam/index.html Show resolved Hide resolved
core-aam/index.html Show resolved Hide resolved
<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> &lt;value&gt;</span>
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 😅

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

<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> &lt;value&gt;</span>
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

core-aam/index.html Outdated Show resolved Hide resolved
<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>
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@rahimabdi
Copy link
Contributor

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

[CEReactions] attribute FrozenArray<Element>? ariaActionsElements;

@smhigley
Copy link
Contributor Author

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

  • 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
Copy link
Contributor Author

smhigley commented Sep 23, 2024

@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
Copy link
Contributor Author

smhigley commented Sep 23, 2024

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
Copy link
Member

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

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

@smhigley
Copy link
Contributor Author

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

@tranjocelyn
Copy link

I think there are some edge cases that haven't been discussed yet. What should we do if

  • aria-actions points to a non-descendant, is that ok?
  • aria-actions points to something invisible?
  • the element with aria-actions doesn't have focus?

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@smhigley
Copy link
Contributor Author

I think there are some edge cases that haven't been discussed yet. What should we do if

  • aria-actions points to a non-descendant, is that ok?
  • aria-actions points to something invisible?
  • the element with aria-actions doesn't have focus?

Great questions! I'll go in order:

  • yup, totally OK to point to a non-descendant! We've talked about descendants a lot because they have more side effects (changing the accName name-from-content algorithm and having a special exception in the allowed content model), but non-descendant actions should be normal and fine 😊
  • Hm, I dunno if I'd expect browsers to check if the reference element is visible. Is that a possibility, at least for things that remove elements from the a11y tree like display: none and visibility: hidden?
  • This is related to some of the stuff we discussed at TPAC, around adding an AriaAttributes / ObjectAttributes mapping of aria-actions: "" so when the element is not in focus, screen readers can at least expose the fact that the control is intended to have actions. I'm assuming the other mappings would only exist if the referenced action elements exist in the DOM (which they might not until the referencing element gains focus). I'd defer to you for specifics on whether Chrome even looks for the referenced elements while the referencing element does not have focus though.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense to me, FWIW. But yeah, I think @jcsteh's sign-off is more important :D

@cookiecrook
Copy link
Contributor

  • [What if] aria-actions points to a non-descendant, is that ok?
  • yup, totally OK to point to a non-descendant! We've talked about descendants a lot because they have more side effects (changing the accName name-from-content algorithm and having a special exception in the allowed content model), but non-descendant actions should be normal and fine 😊

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.

  • [What if] aria-actions points to something invisible?
  • Hm, I dunno if I'd expect browsers to check if the reference element is visible. Is that a possibility, at least for things that remove elements from the a11y tree like display: none and visibility: hidden?

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 opacity:0.

Great point that this should be agreed upon language in the spec.

  • [What if] the element with aria-actions doesn't have focus?
  • This is related to some of the stuff we discussed at TPAC, around adding an AriaAttributes / ObjectAttributes mapping of aria-actions: "" so when the element is not in focus, screen readers can at least expose the fact that the control is intended to have actions. I'm assuming the other mappings would only exist if the referenced action elements exist in the DOM (which they might not until the referencing element gains focus). I'd defer to you for specifics on whether Chrome even looks for the referenced elements while the referencing element does not have focus though.

I recall we discussed :focus-in may be okay, but I can't recall where we landed. I do recall the concern that AT should not announce "Actions Available" for everything within a <main> element that has actions (and I agree, FWIW), but I think that's an implementation detail. I also recall we agreed aria-actions="" on any descendant would override (not concat) the actions list, so author would have an override ability.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
spec:aria waiting for implementations Cannot be merged until there are two browser impls or one impl + impl commit
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Secondary actions on items in composite widget roles