You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem
While using the coachmark, we're hoping to draw folks attention to it, visually (and someone who is familiar with the platform) they will see it right away and consume that content. However, for an assistive tech (AT) user they won’t have that same experience and will only discover the coachmark in the process of exploring the page. Depending on how it is implemented, this may appear in the DOM before or after the feature that it is "pointing at". Additionally, there is no clear indication of what the coachmark is "pointing at", users will only discover a tooltip widget but won't benefit from the visual cue of the arrow/triangle to indicate what it's associated with. Users who rely on AT may have difficulty understanding the purpose of the coachmark or that it is there at all.
The solution
There should be some options available that allow the coachmark to be one of (if not the) first focusable item on the page. This will give the same experience as visually perceiving it upon page load as well as allowing users to dismiss it in case it obscures content/controls while open. We may need to research how to emit the coachmark out of something like an MFE to the global space to allow it to be placed at the start of the page.
For the programmatic association, research may be needed to implement aria-describedby or similar ARIA associations. However, known issues with the encapsulation of the shadow DOM do exist and may pose issues until browser/AT support emerges.
Alternatives considered
If we don't move the coachmark to the start of the page, careful consideration will need to be made about where in the DOM the coachmark will appear so it's discoverable inline. We may need to include explicit documentation about its use on pharos.jstor.org.
The text was updated successfully, but these errors were encountered:
The problem
While using the coachmark, we're hoping to draw folks attention to it, visually (and someone who is familiar with the platform) they will see it right away and consume that content. However, for an assistive tech (AT) user they won’t have that same experience and will only discover the coachmark in the process of exploring the page. Depending on how it is implemented, this may appear in the DOM before or after the feature that it is "pointing at". Additionally, there is no clear indication of what the coachmark is "pointing at", users will only discover a tooltip widget but won't benefit from the visual cue of the arrow/triangle to indicate what it's associated with. Users who rely on AT may have difficulty understanding the purpose of the coachmark or that it is there at all.
The solution
There should be some options available that allow the coachmark to be one of (if not the) first focusable item on the page. This will give the same experience as visually perceiving it upon page load as well as allowing users to dismiss it in case it obscures content/controls while open. We may need to research how to emit the coachmark out of something like an MFE to the global space to allow it to be placed at the start of the page.
For the programmatic association, research may be needed to implement
aria-describedby
or similar ARIA associations. However, known issues with the encapsulation of the shadow DOM do exist and may pose issues until browser/AT support emerges.Alternatives considered
If we don't move the coachmark to the start of the page, careful consideration will need to be made about where in the DOM the coachmark will appear so it's discoverable inline. We may need to include explicit documentation about its use on pharos.jstor.org.
The text was updated successfully, but these errors were encountered: