Widgets

Juxtapose helps storytellers compare two pieces of similar media, including photos, and GIFs. It’s ideal for highlighting then/now stories that explain slow changes over time (growth of a city skyline, regrowth of a forest, etc.) or before/after stories that show the impact of single dramatic events (natural disasters, protests, wars, etc.).

Whether you build a widget as a web component using standards, Vue, React, or any other framework, or with a combination of HTML and JavaScript, screen readers that encounter your widget will look for clues in the rendered markup to discern what it is and tell users that they’ve encountered a search box, menu, or carousel.

Screen readers generally follow this order of precedence:

1. Look for explicitly set ARIA attributes (roles, states, properties), and in the absence of those:
2. Interpret any implicit roles from markup semantics (form elements, paragraphs, lists, etc).
3. Read any text available in the markup.

If no discernable semantics exist (think ARIA-less <div> or <span> tags), it skips to #3. So when you omit ARIA, you’re rolling the dice on whether users will understand that your <ul> is a menu and not simply a list. When you omit ARIA and semantic tags, you’re leaving it up to your users to figure things out (and potentially abandon your product because it doesn’t work).

This is a fascinating deep dive by the people at Discord on their development of a focus ring component and all the problems they had to overcome:

Browsers implement default focus rings that apply to all elements, but the ability to style these is (currently) very limited. These rings, while they have recently improved greatly in Chrome and Edge, are also not very pleasant when integrated with the rest of Discord’s design, and other browsers like Firefox are almost entirely invisible in most cases due to the thinness and low contrast of their styles.

As such, we want to implement a custom focus ring style. At a glance, this seems relatively simple, but when dealing with the variety of use cases Discord has for these rings, the list of requirements quickly grows, and the options for implementations shrink.

Ideally, we want to match the browser’s focus ring behavior exactly. Within Discord, this means that a comprehensive focus ring implementation needs to:

• Perfectly map to the element that has focus (with exceptions listed below).
• Follow elements as they move when containers scroll.
• Follow elements as they animate and transition within the document.
• Not be clipped off when the focused element is bounded by overflow: hidden or other bounding techniques.
• Respect occlusion of overlapping elements, but not be occluded by an element’s own z-index.

Additionally, to be able to implement pleasant and overall better focus styles for various elements in the app, we have additional requirements to be able to:

• Apply the focus ring on a different element than the actual focused element
• Provide positional offsets to adjust ring placement around the element.
• Adjust ring styles to match the look and feel of the surrounding context (could include changing border radius, color, shape, and more)
• Specify a style for when focus is within an element, for example to indicate the bounds of a widget.

See the source link for the rest.

Little #a11y tip for you: If you are using a status message bar, you’ll want it to be a live region. But it should aslo be discoverable in case the messages are missed when they’re announced. Good case for an <aside>:

<aside aria-live="polite" aria-label="Status">
  ...
</aside>

A11Y Nutrition Cards is an attempt to digest and simplify the accessibility expectations when it comes to component authoring. Based on the WAI ARIA Authoring Practices Guide.

This is pretty neat: an accessible drag and drop component that works with keyboard as well as a pointer.

Carousels (or ‘content sliders’) are like men. They are not literally all bad — some are even helpful and considerate. But I don’t trust anyone unwilling to acknowledge a glaring pattern of awfulness. Also like men, I appreciate that many of you would rather just avoid dealing with carousels, but often don’t have the choice. Hence this article.

Carousels don’t have to be bad, but we have a culture of making them bad. It is usually the features of carousels, rather than the underlying concept that is at fault. As with many things inclusive, the right solution is often not what you do but what you don’t do in the composition of the component.

[…]

• Use list markup to group the slides together. Then screen reader users in ‘browse’ mode can use list navigation shortcuts to traverse them.
• Provide a reasonable experience in HTML with CSS, then feature detect when enhancing with JavaScript.
• Don’t preload content users are not likely to see. Defer until they perform an action to see it.
• Provide generous touch targets for touch users on mobile / small screens.
• If in doubt of a control’s (or widget’s) affordance, spell it out with instructions
• If you are a man and got past the first paragraph without being personally offended: Congratulations! You do not see men and women as competing teams.

Most of the time, tooltips shouldn’t be needed if you provide clear textual labeling and familiar iconography. Most of the time toggletips are a complex way of providing information that could just be part of the document’s prose content. But I see each of these components all the time in auditing websites, so I wanted to provide some guidance on how to make the most of them.

Checklist

• If you have space, don’t use tooltips or toggletips. Just provide clear labels and sufficient body text.
• If it’s a tooltip you are looking to use, decide whether the tip’s content should be provided as the label or description and choose ARIA properties accordingly.
• Don’t rely on title attributes. They are not keyboard accessible and are not supported in many screen reader setups.
• Don’t describe toggletips with aria-describedby. It makes the subject button non-functional to screen reader users.
• Don’t put interactive content such as close and confirm buttons or links in tooltips or toggletips. This is the job of more complex menu and dialog components.

How you design and implement your toggle buttons is quite up to you, but I hope you’ll remember this post when it comes to adding this particular component to your pattern library. There’s no reason why toggle buttons — or any interface component for that matter — should marginalize the number of people they often do.

You can take the basics explored here and add all sorts of design nuances, including animation. It’s just important to lay a solid foundation first.

Checklist

• Use form elements such as checkboxes for on/off toggles if you are certain the user won’t believe they are for submitting data.
• Use <button> elements, not links, with aria-pressed or role="switch" plus aria-checked.
• Don’t change label and state together.
• When using visual “on” and “off” text labels (or similar) you can override these with a unique label via aria-labelledby.
• Be careful to make sure the contrast level between the button’s text and background color meets WCAG 2.0 requirements.

See the source link for very detailed descriptions of all of these points.