I have a web application and I’d like to let an AT know more about it. The tricky part is that documents are embeded in my application as well.
I know its possible using the W3C WAI-ARIA specification to inform an AT about the type or role of a document via the role tag. The role tag can be used to define an area as either a document or an application. Since applications in often have a lot of user defined keyboard shortcuts and navigation, its important to let an AT know that the defaults should be ignored. Documents have some great pre-defined behavior like keyboard navigation, so identifying a related area as a document is a major plus for users. The table below gives a bit more detail about the two roles.
role=document Enable additional keyboard and commands support to improve access to information.
role=application Disable additional keyboard and commands so the developer can define them
Given the role=application or document options, the application role seams more important since the web page is an application primarily. This will allow all containers/areas to inherit the application role along with any behavior I define. Though this application will have a few embeded documents where I would rather use the document role defaults than my defined behavior. Since, the role property can be nested where a document role can be located within an application role, my best option is to have a top level role=application on the body of the web page and a role=document on any document containers within my application. See the basic code example below.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml"
xmlns:aaa="http://www.w3.org/2005/07/aaa">
...
<body role="application">
...
<div role="document">
...
After trying a few implementations I found applying the role=application attribute to the body tag worked beautifully. This allowed my defined behavior including keyboard navigation to be available throughout my application and the AT did not override any of my behaviour. Applying the role=document tag is a bit more tricky: do I apply the attribute to the nearest document element or to the nearest container or does it even matter? I found applying the document attribute to whatever the highest level div that acted as a container for the document worked best.
By nesting the role=document attributes within the role=application attribute I was able to get the best of both worlds. My defined behavior was not overriden by an AT, except within a document where the default behavior of an AT took over. This is perfect for my users who can use my intended keyboard navigation etc. through my application but also receive the keyboard defaults s/he is use to when navigating a document.