Create badge/pill design system

[joe-watkins]

As noted in #513 (comment) we are needing a cool / easy-to-use badge/pill design system integrated into the site.

Will try this system out on the patterns page. Needs to be flexible so that it works in other areas of the site ;)

[gallexi]

👋 Hi, I'd love to try to tackle this!

[svinkle]

Hey @galantlex! Thanks so much, that would be awesome! Let me know your thoughts on what a solution might look like.

Looking forward to hearing what you come up with! 🙂

[svinkle]

(I can't assign this ticket to you directly @galantlex but I'll assign to myself and we can work on this together.)

[gallexi]

I'm pretty new to the world of design in general, so just to be clear, when you say "pill/badge", do you mean maybe something like this?

[svinkle]

@galantlex Yeah, that looks pretty great to me!

I'm thinking it would be cool to just have the icons visible beside the link text, then on link :hover+:focus, display the framework name. This way the focus is more on the link itself and what it is, rather than the tech behind it.

[gallexi]

Makes sense! In that case do you think there should be a border around it at all, or really just the icon? Especially since some icons (react, angular) seem more self-encapsulated than others (vanilla).

[svinkle]

@galantlex Good point. I think just the icons only would look pretty slick. The vanilla JS icon could be the yellow square with black "JS" text, as seen on many a laptop. 🙂

[kendrick]

@galantlex Happy to chip in on this if you need help/opinions!

[jenstrickland]

Also, happy to help here. I wanted to ask if color contrast is a concern for the icons.

[svinkle]

@jenstrickland Excellent! For contrast, we can't do anything when using brand logos. However, if we add plain text or a custom border for the design, that's when we need to account for color contrast.

@galantlex, curious if you were able to make any more headway with this? If not, no worries!

I'd like to see a decision made for a design concept first before anyone takes on the coding bit.

I like the concept displayed above, but thinking it could be more simplified with the logo and perhaps a tooltip on hover and focus? Or, just plain text beside the logo. Thoughts?

[jenstrickland]

@galantlex If I can help, please let me know.

[gallexi]

Hi yes sorry!

I like the idea of just a logo + tooltip with name on hover. One thing I'm thinking there is we should make sure the area on which one can hover is large enough so that it's accessible without super fine motor control. Otherwise, should be good!

[svinkle]

@galantlex Good idea on the large hover area! Also be sure to include the same treatment on focus as well for keyboard-only folks.

What we'll need to actually implement this feature:

1. Logo assets (preferably SVG format if possible.)
2. Custom tooltip feature for hover and focus states (I'm partial to my own solution, but feel free to come up with something new and unique!)
3. A new data entry point for the patterns.yml file. Perhaps something like code:. For code entries we could have, js, react, angular, jquery, css, etc.
4. Update the patterns.html template in order to interpret and output each logo when found from the patterns.yml file.

For each task please create a new branch and send PRs when you've got something ready to show.

So, Team Badge/Pill Design System, @galantlex @jenstrickland @kendrick, who's interested in doing which task?

[gallexi]

I'm a university student about to start finals, so I'd love to hit 3 and/or 4 starting after next week, possibly after others have done 1 and 2?

[jenstrickland]

I'm grabbing the svg logos. So far, I have jquery, react, angular, nodejs. Not finding a CSS logo, nor am I aware one exists. For simplicity's sake, I think using the code you provided on CodePen is great. I can take a look at the patterns.yml/html tomorrow.

[svinkle]

Right, there's no "official" CSS logo per se, but folks seem to be partial to the blue shield style logo. Also thinking it would be nice to have a Sass logo, in case the author is using Sass for their styling. We can always add more as we find them.

[jenstrickland]

Work started at: https://gist.github.com/jenstrickland/dd496d1c60d1c27d01dc5c41a6e15277 Is this where I should start the work, or should I do a pull request?

[svinkle]

@jenstrickland I'd say create a new branch with your work and do a pull request. This way we can not only have a code review but also pull down the branch and try it out locally. 👍

[jenstrickland]

@svinkle Cloned the repo and have everything set up. Do you want these styles to go into _layout.scss or would it be more helpful to create a _badges.scss?

[svinkle]

@jenstrickland I think a new .scss file makes sense. 👍

[svinkle]

I was just thinking since the badges are merely tooltip in this context, the markup will need to reflect this. It'll be a little different from my original pen. Hmm, I should fork my pen and make a non-link list demo. 🤔

I was also thinking how it would be neat if we had a filter feature. For example, filtering by "JavaScript" would only show vanilla JS demos. We can save this for a later time though. 😅

[jenstrickland]

@svinkle @galantlex @ericwbailey I'm inclined to not include the svg in the code but to put the icon in CSS as a background image. I would include a link with span with aria role="tooltip" within each pattern item that includes the name text. The span would initially only show the icon, and become wider on :hover and :focus to reveal the text for the framework. Here's a sample of what I'm thinking: https://www.jenstrickland.design/experiments/ I need to add more visual design to it, if you think this is a valuable direction. What do you think?

[svinkle]

@jenstrickland I like the direction this is heading!

Thoughts on SVG usage…

A couple reasons I'd suggest using an SVG sprite instead of CSS background images:

• SVG directly in the markup has a perf gain as the client is just downloading text. When used as background image, each image is a separate request to the sever.

  

• When images are included with the CSS background property, they don't display in Windows High Contrast themes.

  

I like your ideas on the design! Keep up the great work. 👍

General ARIA tooltip thoughts…

I was also testing with a desktop and mobile screen readers. Your markup is correct in the sense that this is generally the recommended approach for tooltips, but I just can't wrap my head around this recommendation. I have this pen, Thoughts on the WAI-ARIA Tooltip spec, with what makes sense to my brain.

Pretty sure @scottaohara and I have discussed this briefly in the past. I just don't understand how a link that goes nowhere on click is a good approach?

[ericwbailey]

+1 to @svinkle's thoughts on SVG spriting.

The pattern @jenstrickland is proposing runs aground of some issues Heydon wrote about with Toggletips in Inclusive Components. What about wrapping the badge logo itself in aria-hidden="true", then visually hidden text that reads "Uses $technology."? My thinking is when a SR reads it, it'll construct a sentence that reads, "Dropdown Alternative. Uses JavaScript."

It seems like a big ask to have a SR user manually toggle each tooltip to reveal what technology powers it if reading through a list. Destination-less links also rub me the wrong way, as well as concerns for hover-capable only behavior.

[jenstrickland]

@svinkle This was awesome! It's been such a long time since I've been able to collab with devs.
@ericwbailey The CSS I used was similar to Heydon's visually hidden. My understanding is that it is available to SR without a toggle. I added "Uses" before the framework — thoughtful!

From reading the spec, spec-in-progress, Heydon's work, plus Sara Souieden's notes, I agree hrefs that go nowhere are not ideal, and disagree with Sara onbutton because in this implementation it toggles state. I do think labelling the tip itself with role="tooltip" makes sense, but it seems a tooltip trigger is missing from the construction as a way of pairing a trigger with a tip. Relatedly, aria-labelledbyand aria-describedby need unique id(s) but these wouldn't have unique ids, unless I'm missing something. We'd re-use the svg + tooltip for each pattern link that uses a framework. Tooltips seem akin to classes more than ids.

https://codepen.io/jenstrickland/pen/RxoMMo

[ericwbailey]

@jenstrickland Ah, missed that on my first pass. Apologies!

[jenstrickland]

I was worried about users on browsers without SVG support & not using a SR. As things stand now, they get neither the icon cue or the tooltip. Should we address this? Also, I just checked CanIUse and see SVG basic support is a lot better than I thought! Should we have a solution for IE <9, Android <3? @ericwbailey @svinkle @galantlex

This solution is also quite a bit different from the original "pill" — is this okay, or would you like more visual design attention brought to it? I need to make the SVG sprite sheet, too.

[scottaohara]

Hey all,

So I've been reviewing the thread and the current state of the suggested pattern, and I think we're missing the mark here a bit.

We really shouldn't need a tooltip for this, especially if we want this to be an easily reusable pattern that doesn't require the use of IDs. Properly using a tooltip role requires the need for IDs and aria-describedbys.

As @svinkle has mentioned, he and I have spoken about the tooltip role in the past, and our problems with it. Atooltip is not meant to be focusable itself, and is meant to be associated with an element that has additional information associated with it.

So when a user focuses an element with a tooltip, the accessible name would be announced first, and then the tooltip would be announced as the description, to mimic the behavior of the title attribute, as is the purpose of the tooltip role.

Presently, there are no special hooks to indicate that a tooltip is present with screen readers, if you follow the specification. So right now, the role is pretty much useless, because it is not supposed to be focused itself, it doesn't show up as a landmark or anything, and aria-describedby does all the actual work of associating the descriptive content with the primary focusable element.

So with that out of the way, in reviewing the present pattern, I've seen it is setup as such:

<a href="#">pattern name</a>
<button><svg></svg><dfn role="tooltip">uses ...</dfn></button>

This is problematic for a couple of reasons.

1. Even if tooltips were announced in some way, this pattern would be confusing for a screen reader, as the tooltip lives inside of the button. Should this be the accessible name of the button? If a screen reader understood tooltips, would this tooltip be dissociated with the button and announced as the content describing the button, which in turn wouldn't have an accessible name because its only labelled child node was the tooltip?
   Right now, the button(s) are announced as "Uses X". The tooltip role itself isn't announced at all, which makes sense, because it's a child of the button. The dfn also serves no purpose here as again, the button is the focusable element whose semantics take precedent.

2. The a and buttons are associated with each other from being in the same li, but the information is not as easily discoverable as it could be. Having the various different focusable elements means that each pattern listing could consist from 2-3 focus stops. 1. name, 2. css, 3. js of some type. This just makes this listing much harder for keyboard users to have to interact with, and for AT users navigating by say, links, they would not hear the associated languages with each pattern, as those languages exist in buttons that are not "connected" to the a.

Long story short, let's not confuse wanting a visual hover/focus visual "tooltip" as an a tooltip. We can have the former without the latter.

For instance:

<li>
  <a href="#!">
    Pattern Name
    <span class="visually-hidden">
      - uses: 
    </span>
    <span class="not-a-tooltip-tooltip"> 
      <svg role="img" aria-label="CSS" focusable="false" />, 
      <svg role="img" aria-label="JS Whatever here" focusable="false" />
    </span>
  </a>
</li>

So the above would do the following:

1. Keep the pattern as a single focusable item
2. The visually hidden " - uses: " would bridge the pattern name, with a pause from the "-" announce the "uses", and the ":" would create another pause before going right into the listing of languages
3. The attributes on the SVGs serve to ensure the SVGs are understood correctly in more browser/ATs, give them accessible names with the aria-labels, and decrease the possibility that IE will get all focus happy and try to focus down the SVG's DOM.
4. The commas between the SVGs can be hidden via color: transparent;. So the not-a-tooltip-tooltip could still be revealed via changing the opacity or the display value of the element, while the text within can remain hidden. We want these commas here so that the SVG names aren't all read as a single text string without pauses between the labels.

OK. That's all I got for now. Hope this has been helpful and the issues I outlined are clear.

Thanks

[svinkle]

@scottaohara Totally agree. This markup structure is really great. Main issue I see is if someone wants to know what the icon represents, it would be nice to have something available on focus/hover, thus the original idea of the "tooltip" (or tooltip.)

[jenstrickland]

@svinkle @scottaohara @ericwbailey @galantlex I keep wondering why we hide the text that pairs with the icon? We have the space to display the icon and label, it will be clearer for novices, and accessible. Why are we hiding it?

[svinkle]

I agree with @jenstrickland; the text should be visible. See #531 (comment).

[ericwbailey]

Closing this issue for inactivity, thank you to everyone for their contributions. Please feel free to re-open the issue if you would like to continue working on this feature.