Juicy Studio is an independent UK website, run by Gez Lemon. It's an unfortunate surname, but explains why the site is Juicy.
When life deals you a lemon, make a lemon meringue pie.
The mission of this website is to promote best practice for web developers in a fast moving industry. Whether you're a novice or a professional, there's something for you.
Hidden label Firefox bug
The standard method for hiding text visually to retain a clean design but provide context for screen reader users is to use the CSS clip technique. Due to browser bugs with the clip property, other declarations are used to make this technique work correctly across different browsers.
Two of the properties used in the additional declarations for the clip technique are position and overflow. Unfortunately, due to a bug with Firefox, when these two properties are used together in a rule applied to the label element (regardless of property value), they cause the label text to not be exposed as the accessible name for the corresponding form control. The position and overflow properties are also used in other techniques for hiding text visually, but this bug means the accessible name will not be available for screen reader users when applied to a label element.
Icon fonts are vector graphics that are included in the content using the CSS content property on a before or after pseudo-class selector. As with regular fonts, icon fonts are scalable and can be styled using CSS, unlike images. They also have the benefit that they remain visible in high contrast on Windows, unlike CSS background images. The biggest drawback from an accessibility point of view is that they won't work if a user's user-defined style sheet overrides the font-family property.
JAWS' implementation of the HTML5 outline algorithm is incorrect with IE and Firefox when the author explicitly specifies the heading levels. Fortunately, there is a relatively simple fix until JAWS finally fixes the bug.
The aria-controls attribute is important for composite widgets where one element controls another, such as navigation widgets (links, buttons, or tabs controlling another section), tree views, and similar relationships where one element controls another. The attribute defines the relationship so that assistive technology users can navigate to the content effected by the controlling element; for example, from a tab to the associated tab panel.
Considering the importance of being able to define these relatively simple relationships, the aria-controls attribute has surprisingly poor support. The only browser/assistive technology combination that I'm aware of that supports this relationship at the moment is Firefox/JAWS.
Most of us have come across scenarios where web accessibility testing with assistive technologies produces unexpected results, when we know the underlying structure of the web page is correct. Assistive technologies are complex, so it's not surprising they sometimes go wrong, but we need to know how to recover when they're being unresponsive or providing incorrect information. My colleague, Hans Hillen, sent an email internally at TPG about handling erratic behaviour with JAWS, and has kindly allowed me to post it here, as this is useful information.
What techniques do you use to handle strange behaviour in JAWS and other assistive technologies?
Custom-built dialogs are common in web-based applications, but many are not accessible. Most of them are not announced to assistive technologies, and so screen reader users are not made aware that a dialog has been launched. Many are also not focused when they are launched, and so keyboard-only users are still focused on elements in the background, and might have to navigate through the content in order to reach the dialog.
The WAI-ARIA specification defines roles and attributes that help ensure dialogs are announced correctly to assistive technology users, and provides guidance on ensuring they are keyboard accessible.