bmlt-enabled / bmlt-workflow

supports automation of meeting adds/changes/deletes
Other
4 stars 3 forks source link

Tooltip Accessibility #42

Closed klgrimley closed 2 years ago

klgrimley commented 2 years ago

Few things here, but I think a single issue is best for now.

Quick breakdown of what constitutes an accessible tooltip. 1) triggered by either hover or focus 2) can be dismissed without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content 3) the new content doesn't disappear when the pointer is moved on top of it 4) content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid

Currently what I'm seeing... 1) not focusable 2) only activates on hover 3) mostly hoverable 4) no keyboard method to dismiss content

What needs done 1) Add a tabindex to the tooltip and apply the :hover to :focus also. This should solve points 1 and 2 2) JS to dismiss content when esc is pressed. This should solve point 4 3) point three is probably a non issue. If css is simple maybe close or bridge the gap so a slow moving cursor doesn't cause the content to disappear

I'll try and get a pull request in to address these by the weekend. Just wanted to get this recorded while it was fresh in my mind.

klgrimley commented 2 years ago

I'm starting to see some instances where the "traditional" tooltip is being refactored in favor of an accordian, or at least accordion like functionality. The initial setup is still the same, with the same indicator and all that. However instead of a hover effect it's now clickable and drops opens with the content. That pretty much solves the potential accessibility issues. And is also a viable solution to the initial reason for wanting a tooltip.

nigel-bmlt commented 2 years ago

have merged the PR as part of 0.3.10. will consider accordian styling if more tooltips are required!