Problem/Motivation
at the moment the tour button has an aria-pressed attribute. problem with that, for screenreader user that doesn't have much benefit, cuz technically as soon as the button is pressed everything except the tip dialog modal gets "hidden" behind the greyed out svg, or on second look it at least should, but at the moment the admin_toolbar is spared from being greyed out in contrast to the jquery ui dialog modals in drupal core where the admin_toolbar is greyed out as well.
Currently the dialog modal for a tour tip is missing the dialog element and or an aria-modal attribute so that everything in the background of the dialog modal gets removed from the accessibility object model. therefore if sheperd would support that the toggle button would be unavailable anyway, so the purpose of a "toggle" button would be obsolet (there will be a to be linked issue upstream). And a toggle doesn't communicate necessarily what happens when a button is toggled. A user not necessarily knows what will happen when the button is clicked.
@andrewmacpherson suggested adding aria-haspopup="dialog" in the issue summary of #2961001: [META] Improve accessibility of tour module, indicating to the user that a dialog will appear. Aside the fact that with the tour dialog modal having a dialog element and or an aria-modal attribute in place removing the button from the AOM it also has to be noted that having aria-pressed alongside the aria-haspopup on the button element leads to the following announcement in voiceover: action toggle button, so aria-haspopup is not getting announced with aria-pressed in place. Removing aria-pressed instead leads to the following announcement: action dialog pop up button. As already mentioned on the parent issue, i've raised the topic at the last a11y office hour and folks were in agreement with the suggestion in the proposed resolution section.
Steps to reproduce
- activate your screenreader of choice
- go to
admin/appearance - go to the tour toggle button
Proposed resolution
- Remove the
aria-pressedattribute from the button element - Add the
aria-haspopup="dialog"to the button element - Create an issue upstream in the shepard repo for using a
dialogelement and or anaria-modalattribute
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | dialogpopupbutton.mp4 | 475.81 KB | rkoller |
Issue fork tour-3469328
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
smustgrave commentedDo we know if this is fixed in shepherd.js version past 10.0.1?
Comment #3
rkolleroh the button markup is generated by sheperd? i've assumed that would be on the tour module and or drupal end? will take a look if i am able to figure it out if sheperd 13 which is the current version i suppose is supporting it.
Comment #4
smustgrave commentedThe aria-pressed I believe is in tour module but the upstream issue may already be addressed too
Comment #5
rkolleri've checked alpha13 of shepherd 12.0.0. ( i guess that is the latest). the dialog element/aria-modal issue for upstream is still necessary. shepherd-element.svelte uses a div and doesnt have the aria-modal attribute either ( i am only on the feedback from mike, just asked him as a reality check before i create the issue upstream). and on the button in shepherd-button.svelt i also dont see aria-pressed nor aria-haspopup. so probably it would make sense to open an issue upstream for that as well. guess both should happen in combination.
Comment #6
smustgrave commentedWe can least improve things on our end.
Comment #7
smustgrave commentedComment #9
smustgrave commentedProbably need to open an upstream issue.
Comment #10
rkollerwith voiceover i've tested with safari (see and listen in the video), firefox and edge on macos and the dialog popup is announced properly across all browsers. looks good!
in regards of the upstream issue. do you mean opening an issue in regards of aria-haspopup there as well or do you refer to the dialog element topic? for the latter i've already opened an issue: https://github.com/shepherd-pro/shepherd/issues/2959. i am just battling with the shepherd environment run within ddev (the problems are also mentioned on the issue). otherwise i would already tried opening a pull request (or at least tried if i am able to change the markup to a dialog element locally in a first step).
Comment #11
smustgrave commentedSo currently I'm doing some hacky way to make sure the attributes are there since don't have a way to know if or when it would be fixed upstream in shepherd.