Accessibility can be a complex and difficult topic. The Accessibility Project understands this and wants to help make it easier to implement on the web. Our goal is to accomplish this with three principles in mind:
- Digestible. We strive to feature short, digestible pieces of content.
- Up-to-date. The project is hosted on GitHub so information can be current with the latest standards.
- Forgiving. People make mistakes, so we seek to be encouraging.
This looks like an excellent, accessible starting point for the priority navigation pattern:
Or the priority navigation pattern, or progressively collapsing navigation menu. We can name it in at least three ways.
There are multiple UX solutions for tabs and menus and each of them have their own advantages over another, you just need to pick the best for the case you are trying to solve. At design and development agency Kollegorna we were debating on the most appropriate UX technique for tabs for our client’s website…
We agreed it should be a one-liner because the amount of tab items is unknown and narrowed our options down to two: horizontal scroll and adaptive with “more” button. Firstly, the problem with the former one is that horizontal scroll as a feature is not always visually obvious for users (especially for narrow elements like tabs) whereas what else can be more obvious than a button (“more”), right? Secondly, scrolling horizontally using a mouse-controlled device isn’t a very comfortable thing to do, so we might need to make our UI more complex with additional arrow buttons. All considered, we ended up choosing the later option[.]
May 17th is Global Accessibility Awareness Day. See the source link for more. The participate page is a great list of things to test for and be aware of.
The target audience of GAAD is the design, development, usability, and related communities who build, shape, fund and influence technology and its use. While people may be interested in the topic of making technology accessible and usable by persons with disabilities, the reality is that they often do not know how or where to start. Awareness comes first.
This is pretty neat: an accessible drag and drop component that works with keyboard as well as a pointer.
This seems like a useful resource: a list of test results for various screen readers and browser combinations, in what they support and how they behave when encountering certain elements, attributes, etc.
[S]upport aside, it’s still not a particularly good choice as a consistent means to convey accessible information. Because while the
titledoes provide an accessible name to elements in the absence of other sources, it is considered a fallback. Outside of some notable exceptions (more on this later), other mechanisms will always be preferred.
titleattribute can be used on any HTML element, it’s essentially wasted on most inline, text level elements. As these elements aren’t typically included in the accessibility tree, there’s no reason for a screen reader to look for a
titleon these elements to announce.
Block-level wrapping elements can get some usage out of the
titleattribute. JAWS, NVDA and VoiceOver will all announce a
titleon elements like landmarks (
main, etc.) but support may vary on other elements depending on your browser pairing. For example, JAWS will not announce a
Other wrapping elements, like lists and paragraphs, are announced in JAWS and VoiceOver, but NVDA ignores the attribute on these elements. But honestly, using
titletooltips on these elements is highly suspect. Why would you want to have a tooltip constantly appearing over a large chunk of content? Unless you are purposefully trying to hide content, which isn’t helpful, there’s little need for using the
titlein this manner.
Images, form fields, and anchor links are the elements one is most likely to associate with the
titleattribute. In regards to screen readers, the title attribute essentially gets a “B” grade when reviewing publicly available screen reader support charts from powermapper.com.
titles are meant to serve as descriptive text. And largely only in situations where there is no accessible name for an image, form field, or anchor element, the title will be promoted to the accessible name.
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.
The topic of disabling links popped up at my work the other day. Somehow, a “disabled” anchor style was added to our typography styles last year when I wasn’t looking. There is a problem though: there is no real way to disable an
<a>link (with a valid
hrefattribute) in HTML. Not to mention, why would you even want to? Links are the basis of the web.
At a certain point, it looked like my co-workers were not going to accept this fact, so I started thinking of how this could be accomplished. Knowing that it would take a lot, I wanted to prove that it was not worth the effort and code to support such an unconventional interaction, but I feared that by showing it could be done they would ignore all my warnings and just use my example as proof that it was OK. This hasn’t quite shaken out for me yet, but I figured we could go through my research.
First, things first:
Just don’t do it.
A disabled link is not a link, it’s just text. You need to rethink your design if it calls for disabling a link.
Surefire way: remove the href
If you have decided that you are going to ignore my warning and proceed with disabling a link, then removing the
hrefattribute is the best way I know how.
Straight from the official Hyperlink spec:
areaelements is not required; when those elements do not have
hrefattributes they do not create hyperlinks.
An easier to understand definition from MDN:
This attribute may be omitted (as of HTML5) to create a placeholder link. A placeholder link resembles a traditional hyperlink, but does not lead anywhere.
Making a link look like a button is materially dishonest. It tells users that links and buttons are the same when they’re not.
For example, we can open a link in a new tab, copy the address or bookmark it for later. All of which we can’t do with buttons.
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.