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

Support LinkAnnotation actions and CustomActions in AccessibilityRenderExtension #1840

Open
alexei-fando-instacart opened this issue Feb 18, 2025 · 4 comments
Assignees
Labels
accessibility enhancement New feature or request
Milestone

Comments

@alexei-fando-instacart
Copy link

Two related requests:

  1. announcement of AnnotatedString actions
  2. announcement of SemanticsPropertyReceiver.customActions

It would be useful to render these strings with AccessibilityRenderExtension.

The latter seems possible with, SemanticsActions.CustomActions.

However, I'm not sure whether the former is possible. Maybe using, SemanticsProperties.LinkTestMarker? The docs say that LinkTestMarker property is for internal use only and not intended for general use by developers.

@alexei-fando-instacart alexei-fando-instacart added the enhancement New feature or request label Feb 18, 2025
@colinmarsch
Copy link
Collaborator

Thanks for creating this issue! Both of these sound like great additions that I will try to get to work on soon to get into the next Paparazzi release.

For the AnnotatedString actions part, I'm just curious what might be the ideal state on your side for what the accessibility snapshots would include? Would something like a list of the available links by their text name suffice?

@geoff-powell
Copy link
Collaborator

Samples of 1. would be awesome for your use case.

Should be straight forward to add support for the actions specified.

@geoff-powell geoff-powell added this to the 2.0.0-alpha02 milestone Feb 20, 2025
@alexei-fando-instacart
Copy link
Author

@colinmarsch

For the AnnotatedString actions part, I'm just curious what might be the ideal state on your side for what the accessibility snapshots would include? Would something like a list of the available links by their text name suffice?

I think that URLs should not be output because they are long, and are not announced by the screen reader anyway.
Only the action labels, as announced by the Screen Reader should be output.
Not all actions have URLs either. A lot of actions are non-link actions. So outputting the action labels is sufficient to cover every case.

However, it would be useful to discern url actions from non-url actions.

AnnotatedString supports 2 kinds of LinkAnnotation, LinkAnnotation.Url and LinkAnnotation.Clickable. The former is a url action and the latter is a non-url action.

There is another kind of non-url action - a CustomAccessibilityAction, added to a view manually via a semantics call. These actions should also be rendered the same way as LinkAnnotation.Clickable.

Example Output

<url-action-label> - url action
<action-label> - non-url action

The url-action and action are keywords the are hard-coded, and the label is whatever the actual announcement text is.

For example <url-action-go-home>, in which case go home is the announced action text. (Spaces are replaced by hyphens).

@alexei-fando-instacart
Copy link
Author

alexei-fando-instacart commented Feb 25, 2025

@geoff-powell

On second thought. To be consistent, I think that it's useful to distinguish between all 3 types of actions, not just between the 2, like I initially suggested.

The keywords for the 3 types of actions could be:

  1. annotated string Url action - <url-action-....>
  2. annotated string Clickable action - <click-action-....>
  3. custom accessibility action - <custom-action-....>

I don't feel strongly about the keyword labels. Something short and descriptive would be best.

Ordering

It's probably best to draw any annotation string actions first, in the order they appear inside the string, (by span start index), followed by any custom accessibility actions in the order they are defined.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accessibility enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants