Skip to content

Keyboard a11y annotations #805

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

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

Keyboard a11y annotations #805

wants to merge 6 commits into from

Conversation

Dananji
Copy link
Collaborator

@Dananji Dananji commented Apr 15, 2025

Related issue: #781

Copy link
Member

@cjcolvar cjcolvar left a comment

Choose a reason for hiding this comment

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

I tested this out locally with https://yalemssa.aviaryplatform.com/iiif/028pc2tq0m/manifest. This is a big improvement! I had a few questions/observations:

  1. Is there a way to navigate via tab past the annotations? If you tab into the annotations then shift+tab focuses the parent container, but tabbing from there will focus the last focused annotation and tab again will do nothing.

  2. The select-only combobox example ARIA pattern gives some additional key interactions: Home, End, and Printable Characters. Is this the best pattern to be using for the dropdown? Have you thought about implementing these other interactions?

@Dananji
Copy link
Collaborator Author

Dananji commented Apr 17, 2025

1. Is there a way to navigate via tab past the annotations?  If you tab into the annotations then shift+tab focuses the parent container, but tabbing from there will focus the last focused annotation and tab again will do nothing.

Yes, you are right. From looking at other websites it seems tab-order should be cyclic meaning it should wrap back into the browser tabs and to the top of the page eventually. I will take a look at this.

2. The [select-only combobox example](https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-select-only/) ARIA pattern gives some additional key interactions: Home, End, and Printable Characters.  Is this the best pattern to be using for the dropdown?  Have you thought about implementing these other interactions?

The dropdown menu keyboard implementation is a combination of checkbox and menu button which also has a similar set of keyboard interactions as select-only combobox.
I was only considering the common keyboard interactions when implementing this, but I guess it wouldn't be that complex to implement Home and End keydown events. I will also give it a try with the printable character implementation.

@Dananji Dananji marked this pull request as draft April 18, 2025 14:37
@Dananji Dananji force-pushed the keyboard-a11y-annotations branch from 58ad610 to 540cd72 Compare April 18, 2025 15:12
@Dananji Dananji marked this pull request as ready for review April 18, 2025 15:13
Copy link
Member

@cjcolvar cjcolvar left a comment

Choose a reason for hiding this comment

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

This is looking good and really close!

Comment on lines +199 to +200
* Trap focus within the annotation to navigate through any links or buttons in the
* annotation row display when Tab key is pressed
Copy link
Member

Choose a reason for hiding this comment

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

I think this probably shouldn't trap but allow for tab cycling. Maybe it should cycle through only links and show more buttons without regard of the activated annotation? Or maybe only links? What do you think?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

In that case, I need to figure out a way to join the natural tab order of the page once the user is done going through the annotations component.
With cyclical tabbing through all the links and buttons within the annotations component a user might get stuck in that component without a path out of the annotation component... 🤔

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@cjcolvar I don't have any clever ideas on how to implement this without trapping the keyboard navigation inside the annotations component forever. Let me know if you have any.

If it's hard to figure this out at this point, maybe we can circle back to this once we've done some testing on this?

In the comment where I mention trapping the focus within the annotation, it meant enable tab cycling within the focused annotation, but allow the user to get out of it when they press ArrowUp or ArrowDown keys.

@joncameron
Copy link
Contributor

Aviary and other similar applications with annotations or lists of text blocks within embedded links could be a reference point for this.

@Dananji
Copy link
Collaborator Author

Dananji commented Apr 24, 2025

I tested this in Aviary with the Manifest: https://tanyaclement.github.io/SGW-SI/john-wieners-at-sir-george-williams-university-the-poetry-series-8-october-1966/manifest.json. This Manifest has annotations with embedded anchor tags in the annotation text.
Annotations tab allows the user use Tab to focus on each link element within an annotation, but does not allow to focus on individual annotation or timestamp using Tab or Arrow keys. Thus, it does not provide any way to use keyboard navigation to focus on annotations that do not have any focus-able HTML elements such as links.

@Dananji
Copy link
Collaborator Author

Dananji commented May 7, 2025

Additionally I tested the same Manifest in AVAnnotate and it behaves in a similar manner as Aviary. I was able to focus on each link within annotation texts by pressing Tab key but was not able to focus on individual annotation using keyboard navigation.

@elynema
Copy link

elynema commented May 9, 2025

@Dananji I don't know if I have any helpful solutions to the things that are mentioned. What I noticed as problematic:

  1. When I tab into the Annotation list from the menu and use the up/down arrow keys to select an annotation, voiceover reads it at least twice in a row. That's problematic.
  2. In the transcript tab, when I use the up/down arrow keys to select a cue, voiceover reads it once and then provides an instruction to use Ctrl + Option + Enter to select it. Doing that seeks to that cue in the player. It looks like the same keyboard combination works to seek to the beginning timepoint for an Annotation in the annotations tab, but voiceover doesn't announce the instructions.

I think the other question was about getting trapped in the tab group, since tab takes you into the tab detail, so there is no way to get from the Annotations tab into the footer. Is that the problem?

@Dananji
Copy link
Collaborator Author

Dananji commented May 9, 2025

I think not announcing the instruction for activating a selected annotation is problematic. There is a difference between the HTML elements used in the DOM for transcript cues and annotation rows. I will create an issue for that.

Once you are focused on the Annotations and the consecutive tab presses will move focus as follows;

  • 1st Tab press: moves focus from Annotations tab to annotations component tab panel
  • 2nd Tab press: moves focus to annotation set select dropdown
  • 3rd Tab press: moves focus to auto-scroll checkbox
  • 4th Tab press: moves focus to first annotation row
  • 5th Tab press;
    • if the focused annotation row has any focus-able elements (such as links/buttons), the focus will move to the first link/button within the annotation. After that, user won't be able to Tab into the next element on the page and return to the natural tab order because next consecutive Tab presses would cycle through the links/button within the selected annotation. This is a problem!
      • Example of this: the 3rd annotation in the annotation set named 'John Wieners' in this Manifest.
      • Now that I'm looking at this again after some time, I wonder a potential solution would be to not allow user to cycle through links/buttons when an annotation is selected? When focus is on the last link/button, we could break the tab cycle and take the user to the next element in the natural tab order?
    • if the focused annotation row does not have any focus-able elements then user will be taken to the next element on the page's tab order without trapping focus

@Dananji
Copy link
Collaborator Author

Dananji commented May 14, 2025

@elynema I tested the Details tab like we discussed in our meeting to see what it does once a user reaches the last link in the metadata display.

Once the page loads and user is focused on the Details tab;

  • pressing Tab key once moves focus from tab to tab panel containing metadata display
  • pressing Tab key again moves focus to the first link in the metadata display
  • pressing Tab until the user reaches the last link will take them through the metadata display
  • pressing Tab again key will take the user to the next element in the tab order of the page. In Ramp demo site's case this is a button in browser, because there are no DOM elements created after the tab display. And the tab panels that are hidden from user are not in the tab order (in this use-case the transcripts, files tabs) of the DOM. This is the behavior I was seeing in the examples in the accessibility design pattern for Tabs in W3C.
  • to reach the next tab (Transcripts) the user has to Shift + Tab through the list of links in the metadata display and then user Right arrow key

@elynema
Copy link

elynema commented May 14, 2025

Being able to navigate through the content of the Annotations tab is pretty important to accessibility, so this should be included with the Ramp 3.4.0 release.

Sounds like a major remaining concern is the user getting trapped in a specific Annotation that has a link when using TAB. We could:

  1. Leave as is. Users are not really trapped within the annotation because the up/down arrow will move then to the previous or next annotation. This does mean, however, that in order to "break out" of the Annotations tab content, they need to SHIFT +TAB since TAB won't get them out.
  2. TAB should take user to the next link within the Annotations tab content, which may not be within the next annotation. This will probably break the pattern for using SHIFT+TAB to exit the annotations tab content, as presumably it would mean that SHIFT+TAB would take the user to the previous link within the annotation set.

In the details tab, when the users hit TAB on the last link in the content, they are sent to the next link in the tab order, which is the footer in Avalon. I think it makes sense for the Annotations tab to work similarly.

SHIFT + TAB seems to be working ok to me to help a user escape back up to the tab headers themselves. After navigating through the links within an annotation (using TAB), SHIFT+TAB once takes me back up to the annotations container, not to the previous link in the annotation set.

@Dananji @joncameron @cjcolvar Should we talk about this at Swarm next week?

@joncameron
Copy link
Contributor

A new issue can be created for the tab issue mentioned in the last comment. At this point we can probably merge this PR and then resolve the remaining questions and issues for Ramp release. We'll talk about this in the next Swarm meeting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants