A repository of styled and “styled” form control patterns, and how they are announced by screen readers.
Form controls are necessary in many interfaces, but are often considered annoying, if not downright difficult, to style. Many of the markup patterns presented here can serve as a baseline for building more attractive form controls without having to exclude users who may rely on assistive technology to get things done.
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.