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.
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.
There are several techniques for creating tables with static header rows, but very few of the examples I have come across are accessible or do not work cross-browser. This post looks at some of the current solutions, and outlines a method using WAI-ARIA to fix the accessibility issues of the more popular techniques.
The Paciello Group (TPG) is carrying out a mobile accessibility survey. The survey will be available until the end of the month. If you have not taken or shared the survey, please do soon, as your input is valuable and we do not want to miss it.