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.
- 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.
- 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
titleattributes. 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.
- Use form elements such as checkboxes for on/off toggles if you are certain the user won’t believe they are for submitting data.
<button>elements, not links, with
- 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
- 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.
Use scale transforms when animating clips. You can prevent the children from being stretched and skewed during the animation by counter-scaling them.
In this post we’re going to look over what’s involved if you want performant clip animations. If you want to see a demo, check out the Sample UI Elements GitHub repo.
Copying text to the clipboard shouldn’t be hard. It shouldn’t require dozens of steps to configure or hundreds of KBs to load. But most of all, it shouldn’t depend on Flash or any bloated framework.
That’s why clipboard.js exists.