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

Icon Tooltip update for WCAG 2.1 compliance #3115

Merged

Conversation

elizabethsjudd
Copy link
Contributor

Closes #3094

Update to Icon Tooltip to pass AAT ruleset for WCAG 2.1

Changelog

Changed

  • Icon Tooltip trigger now supports using a span within the button instead of the aria-label attribute.
  • To support backwards compatibility and maintain a consistent animation, added bx--tooltip--a11y modifier to the trigger button

Testing / Reviewing

  • Should be tested in Carbon supported browsers (I believe it's Safari, Chrome, Firefox, Edge, and IE11)
  • Use AAT (DAP) to verify the violations no longer are thrown

Before:
Screen Shot 2019-06-19 at 11 40 46 AM

After:
Screen Shot 2019-06-19 at 11 41 33 AM

@netlify
Copy link

netlify bot commented Jun 19, 2019

Deploy preview for the-carbon-components ready!

Built with commit 2d4ef90

https://deploy-preview-3115--the-carbon-components.netlify.com

@netlify
Copy link

netlify bot commented Jun 19, 2019

Deploy preview for carbon-components-react ready!

Built with commit 2d4ef90

https://deploy-preview-3115--carbon-components-react.netlify.com

@netlify
Copy link

netlify bot commented Jun 19, 2019

Deploy preview for carbon-elements failed.

Built with commit 2d4ef90

https://app.netlify.com/sites/carbon-elements/deploys/5d0a5b5c6187780008d79c33

@netlify
Copy link

netlify bot commented Jun 19, 2019

Deploy preview for the-carbon-components ready!

Built with commit f4d6bf1

https://deploy-preview-3115--the-carbon-components.netlify.com

@netlify
Copy link

netlify bot commented Jun 19, 2019

Deploy preview for carbon-components-react ready!

Built with commit f4d6bf1

https://deploy-preview-3115--carbon-components-react.netlify.com

@netlify
Copy link

netlify bot commented Jun 19, 2019

Deploy preview for carbon-elements ready!

Built with commit f4d6bf1

https://deploy-preview-3115--carbon-elements.netlify.com

Copy link
Member

@emyarod emyarod left a comment

Choose a reason for hiding this comment

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

my DAP results don't change from the WCAG 2.0 compliant tooltip to the WCAG 2.1 compliant tooltip, but I think it's because my DAP ruleset is out of date and I'm not sure how to upgrade

image

but from my other testing the WCAG 2.1 tooltip functions and appears like the WCAG 2.0 compliant tooltip

@elizabethsjudd
Copy link
Contributor Author

@emyarod what version of DAP are you using? The latest is 1.8.0.0 and the rulesets should match the screen shot below (make sure you are using the Internal IBM version of DAP that you download through this URL: https://aat.w3ibm.mybluemix.net/tools/auth/tools.html). The external version that you can access through the Chrome store is out of date and doesn't have any of the WCAG 2.1 updates.

Screen Shot 2019-06-19 at 3 08 13 PM

@elizabethsjudd
Copy link
Contributor Author

FYI, my plan was to remove the legacy versions from the demo (so they don't make it on to the website) once the legacy version has been verified to still work with the changes.

@joshblack joshblack requested review from a team and removed request for a team June 19, 2019 20:36
@ghost ghost requested review from dakahn and removed request for a team June 19, 2019 20:37
@joshblack
Copy link
Contributor

@elizabethsjudd just curious, what were the violations that this PR is hoping to address?

{{!-- @todo Had to add a modifier to the parent to correct the animation but in the next major release it could be removed in favor of the new HTML format --}}
<button
class="{{@root.prefix}}--tooltip__trigger {{@root.prefix}}--tooltip--a11y {{@root.prefix}}--tooltip__trigger--icon {{@root.prefix}}--tooltip--left {{@root.prefix}}--tooltip--align-start">
{{!-- @todo Open to suggestions for this element's className; In WH we have a utility class (wh-u-a11yTitle) that can be applied to other components --}}

Choose a reason for hiding this comment

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

seems out-of-scope for this pr, but I'd vote for a global class for these a11y styles as they could be very useful in other situations. Then, {{@root.prefix}}--tooltip__content could bring those in for this use-case, but not have them locked to this component.

@elizabethsjudd
Copy link
Contributor Author

@joshblack with WCAG 2.1 buttons that don't have text in them fail AAT because it reads it as missing a visible label. By moving the content from aria-label to the span the tests are able to recognize that as the label. WCAG 2.1 had a lot of updates where the use of aria-label is going to become a lot more restrictive. Visuals and behaviors with this PR should remain the same as the previous version.

@dakahn dakahn requested a review from snidersd June 19, 2019 20:59
Copy link
Contributor

@dakahn dakahn left a comment

Choose a reason for hiding this comment

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

This looks good to me. Thanks a ton @elizabethsjudd 🏄🏽‍♂️

I'd like @snidersd to get eyes on this since there's a fair few (seemingly much needed) changes. 👍🏽

Copy link
Contributor

@asudoh asudoh left a comment

Choose a reason for hiding this comment

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

Thanks @elizabethsjudd for jumping in!

@emyarod Would you have a chance to test it, especially considering long text (if you haven't done yet)? Thanks!

overflow: hidden;
clip: rect(0, 0, 0, 0);
border: 0;
visibility: visible;
Copy link
Contributor

Choose a reason for hiding this comment

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

visibility:visible undoes visiblity:hidden in an ancestor node. I'd recommend visibility:inherit.

Copy link
Contributor

Choose a reason for hiding this comment

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

@emyarod
Copy link
Member

emyarod commented Jun 20, 2019

@elizabethsjudd unfortunately I'm not able to view the page, I'm just taken to an "Access Denied" even after authenticating. would it be possible to just share the .crx? not sure how to gain access to the a11y tools page you linked

@asudoh yeah it seems fine with long text and functions as expected, but I am seeing the tooltip caret finish animating before the tooltip body though (tagging @shixiedesign for design review). my guess is we can apply the same opacity + animation rules to the caret?

@elizabethsjudd
Copy link
Contributor Author

elizabethsjudd commented Jun 20, 2019

@emyarod what is the .crx? Also, try this link instead: http://ibm.biz/A11yToolsLandingPage (you have to be on the IBM VPN to access and use the internal DAP version)

@joshblack
Copy link
Contributor

Thanks so much @elizabethsjudd! Really appreciate it 🙏

Copy link
Contributor

@shixiedesign shixiedesign left a comment

Choose a reason for hiding this comment

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

Thank you! And especially thanks for double checking the motion part too 🙏

After finally getting to do the review, I noticed a tiny gap between the triangle of the tooltip & the tooltip body box. Vanilla only. @emyarod explained this is also magnification dependent so I'm not sure if there's a fix. If not I guess it's not a big deal, lemme know @elizabethsjudd Everything else looks great!

image

@elizabethsjudd
Copy link
Contributor Author

@shixiedesign thanks for the review! I've noticed the gap between the body and caret as well but I saw it happen with the current implementation. As I was working on the definition tooltip, I noticed that the caret placement was actually quite finicky based on surrounding components/styles that were having odd side-effects with the component. I do feel like it's a valid issue to re-access the caret placement given all of the available demos, but that it's beyond the scope of this PR where I'm really focused on the a11y of the component while maintaining existing behaviors and styles.

@asudoh
Copy link
Contributor

asudoh commented Jun 25, 2019

@elizabethsjudd Though we don't have a guideline for this topic, it'd be great if you can figure out a way to avoid :not() - The way I tend to avoid :not() is having some overriding style that negates original. Probably .bx--tooltip--a11y::after() { content: none; } (more specificity may be needed) for your case?

Copy link
Contributor

@shixiedesign shixiedesign left a comment

Choose a reason for hiding this comment

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

👍 agreed! Thanks for the fix!

@elizabethsjudd
Copy link
Contributor Author

@asudoh out of curiosity, why do you avoid the :not selectors (i've heard pros and cons both ways and was just curious for your reasoning)

Copy link
Member

@emyarod emyarod left a comment

Choose a reason for hiding this comment

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

meant to comment in #3151

@tw15egan
Copy link
Member

@asudoh @elizabethsjudd I'm also curious as to why we should avoid :not selectors. I thought the optimization of css selectors was pretty negligible.

@asudoh
Copy link
Contributor

asudoh commented Jun 27, 2019

@elizabethsjudd @tw15egan Good question from you both! The event I lead to my inclination to avoid :not() has completely slipped off my mind, but a couple of things what I can recall... One is every occurrence of "I don't want this style for this feature" ends up with addition to :not(), like :not(.bx--foo):not(.bx--bar):not(.bx--baz). Also, the style rules of a feature set ends up with with multiple places, one is where :not() is, another is the feature-specific style implementation itself. I'm inclined to having .bx--foo { ... } work for :not() portion as well as for others.

@elizabethsjudd
Copy link
Contributor Author

@asudoh I agree with the fact that :not should be used sparingly in the fact that yes, if you just use it as a fail safe you do end up with bloated selectors as you described. Another reason I have found the :not to be a pain is that it tends leads to higher selector weight making them harder to overwrite. However, in cases like this where we are trying to maintain backwards compatibility I do feel like they are a wash. We still end up with multiple feature specific declarations (the default backwards compatible and then overwriting for the new feature). Right now in tooltip the after pseudo element is actually still getting all of the styles applied to it even though it doesn't use them. which could actually lead to unexpected behaviors for users of Carbon that are trying to extend the styles. I'm good with keeping them removed but I guess I'm saying we shouldn't treat it as a blanket "never use it" but instead assess the situation and figure what is the appropriate solution. It was added to the CSS specification for a reason.

@asudoh
Copy link
Contributor

asudoh commented Jun 27, 2019

Thank you for sharing your thoughts @elizabethsjudd - If I can focus on just one thing, you are right that ::after() gets all the styles even though they are not in use. As far as I see content:none eliminates all the adverse effects by that. And your latest code with content:none seems to have made the change look more straightforward.

@tw15egan
Copy link
Member

@asudoh thanks for filling me in! Makes sense, and I agree in this situation. @elizabethsjudd hit it on the head here:

I guess I'm saying we shouldn't treat it as a blanket "never use it" but instead assess the situation and figure what is the appropriate solution

@asudoh
Copy link
Contributor

asudoh commented Jun 27, 2019

@tw15egan Yes makes sense! - What I meant by my first comment wrt :not() is that good to think twice when we are tempted to use :not().

@asudoh
Copy link
Contributor

asudoh commented Jun 27, 2019

@dakahn Do you think we are good to go? Or should we wait @snidersd? Thanks!

@dakahn
Copy link
Contributor

dakahn commented Jun 27, 2019

@asudoh I'm happy! Let's do it 🏄

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

Successfully merging this pull request may close these issues.

Icon Tooltip: AVT 1 violation
8 participants