Category: aria

Link Roundup – April 2010

Post author By Dennis
Post date May 1, 2010
No Comments on Link Roundup – April 2010

Accessible Documents in HTML, Word & PDF by @terrillthompson from the Digital Accessibility Expo.
Open letter to to U.S. House of Representatives Committee on the Judiciary by @johnfoliot with feedback & accessible testimonies from a government hearing on digital accessibility.
Are sprites accessible?
Accessibility BOF (birds of a feather) Notes from DrupalCon in San Francisco.
Cognitive Web Accessibility Assessments: Lessons Learned So Far
Designing Accessible & Usable App UI for Mobile Phones – slides from #CSUN10 presentation by @berryaccess
W3C update to HTML5: Techniques for providing useful text alternatives by @stevefaulkner.
An ode to ‘Click here’ and to other phrases forcing reading back for context.
Juicy Studio Accessibility toolbar is updated by @gezlemon. Supports ARIA, color contrast, more. (Firefox)
U.S. Access Board’s proposed 508 & 255 standards & guidelines (Draft Information and Communication Technology (ICT) Standards and Guidelines)
Expand and collapse content accessibly with progressive enhancement, jQuery, and ARIA
Do I Have to Learn Programming to Make My Site Accessible? (Even Grounds)
Slide presentations from W4A (7th International Cross-Disciplinary Conference on Web Accessibility)
Expand and collapse content accessibly with progressive enhancement, jQuery, and ARIA.
White House promising more attention to 508
Do we need a new game plan to make the Web accessible? (be sure to read comments)

Adding ARIA Landmark Roles

Post author By Dennis
Post date April 24, 2010
2 Comments on Adding ARIA Landmark Roles

ARIA Landmark Roles were recently added to the Web Axe web site. It’s a great and easy way to add better accessibility to your site, start learning ARIA, and future-proof your site. And it only takes a few minutes, so why not add it into your site? (If you haven’t already!)

An ARIA landmark role is simple an attribute added to a (probably) already existing tag in your site. For example, to add a search role, simple add the attribute role="search" to the tag which contains the search content (the div, fieldset, etc).

Here are some basic landmark roles with links to the W3C definitions:

banner – usually the main header of your site; the area with logo, slogan, etc.
complementary – supporting section of page, separate from the main content, like a sidebar.
contentinfo – area that contains information about the site such as copyright lines and links to privacy notices (i.e. page footer).
main – the main content; area with central topic of the web page.
navigation – a section for navigating the site.
search – a section with a any type of search tool.

In the following example, four landmark roles are used to create a basic page structure.



[header content]


[nav content]


[main content]


[footer content]

Addendum

If more than one type of role is implemented, use the aria-labelledby attribute to give each a unique name. Here’s an example from this web page which has two navigation role attributes.



Previous Posts



Archives

aria navigation screenreader

Screen readers and navigation

Post author By Dennis
Post date January 21, 2010
No Comments on Screen readers and navigation

i navigate by headings when reading a long technical document or news items and essays that are large

i try to navigate by edit box when i can (using edit box navigation, i get the “donate” edit box before the Username edit box on the AccessibleTwitter sign-in/home page, which is a bit unexpected from a user’s point-of-regard)

on pages with multiple forms, since ARIA and the Role Module lack a “form” landmark (the closest thing is “search” – i logged a bug against ARIA 1.0 and the Role Module requesting “form” as a predefined role), i usually use either an AT-generated or a UA-generated list of form fields which is navigatable not just through use of the UpArrow and DownArrow keys, but by first letter of the labelling text

yes, accesskey is problematic with IE as there is no way to cascade ALT+Key so that a user can use the accesskey without conflicting with the UA’s chrome — but FireFox overcame this by using ALT+SHIFT+Key on the windows platform, and Opera has the most customizable accesskey options available anywhere…

my point of view on accesskey is that it does work under the right circumstances, and in those circumstances it is a DEFINITE time and energy saver when one can simply jump-to a particular form and/or form field using an accesskey — to me, the benefits outweigh the drawbacks, but that is simply my opinion, which is both philosophical and practical — or at least so i like to tell myself…

FYI, i’ve been working on accesskey replacement strategies:

1. general HTML A11y Task Force Access (Key) Replacement Wiki Page:
http://www.w3.org/WAI/PF/HTML/wiki/Access

2. Accesskey Replacement Requirements (approved by PFWG years ago):
http://www.w3.org/WAI/PF/HTML/wiki/Access/access_key_requirements

3. a plan to port the XHTML Access Module to a generic Access Element
to address navigation not only in structured, but in stacked, markup
langauages as well:
http://www.w3.org/WAI/PF/HTML/wiki/Access/element_versus_module

4. rob burns’ (robburns1 on twitter) Command & Event and Keyboard
Focus Module:
http://www.w3.org/WAI/PF/HTML/wiki/Access/command_and_event

the
worst offenders are forms inside tables? one has to use table mode to get oriented and check labelling, then switch to forms mode in order to interact with the form fields — aria will definitely help this, but what would help FAR more is if content developers actually abided by the newish verbiage in the HTML5 draft that explicitly bans the use of TABLE for layout or stylistic purposes