| object
| -
Way back in the olden days
when we were developing XHTML Modularization and then XHTML2, the
group recognized that there were lots of pieces of XHTML2 that were
generally useful and that it should be possible to publish them
separately. The concept was that since these were modules
they would be assembled by host language authors as needed, and
then at some point pulled together into XHTML2. Obviously
XHTML2 never came to be, but a lot of the pieces did get worked on
and pulled into other work (e.g., RDFa, Role, all sorts of stuff in
HTML5 although no one will ever admit that).
Today I wanted to talk about the Role Attribute. This piece
of XHTML2 is a deceptively simple attribute. It's purpose is
to help content authors label an element with it's role or roles
within a document. Why do elements have roles? Well -
that's complicated. First, some (more) history...
Sometimes W3C working groups have face to face meetings. At
one such meeting of the XHTML working group (at the AOL
headquarters in Virginia I think) a group member was wearing their
liaison hat between the XHTML working group and the group
responsible for accessibility. They REALLY wanted to be able
to have sections of the document labeled so that assistive
technologies (ATs) could more easily help people with various
disabilities use the web more efficiently. In particular,
things like navigation areas, headers, footers, content,
sidebars... and of course controls. The accessibility
liaison thought it was important that we define a base collection
of roles, but also that it be possible to dynamically extend that
collection of roles easily. The group thought this was a fine idea,
and added the role attribute to XHTML2. The base collection
has been modified over time - you can see its current form in the
Vocabulary Document.
Fast forward to today.
The W3C has today published the Role Attribute as a Candidate Recommendation. A lot has happened in
the W3C community since we started work on this simple attribute,
but the basic form of the Role Attribute and its capabilities has
not changed much at all. There is an attribute named 'role'.
It takes a list of zero or more values. These values
are either pre-defined TERMs (the things in that vocabulary
document), a URI, or a CURIE (a CURIE is a compact URI - a concept
defined by RDFa Core). Assistive Technologies can
use the values of role, in conjunction with other information from
the ARIA
Attributes, to more-or-less automatically make pages more
accessible. RDFa processors can use the information in role
attributes to automatically learn more about the semantics of a
page.
This specification is stable
now. The attribute works in all modern user agents now.
It's values are interpreted by many assistive technologies
already. It is already supported by some RDFa processors,
with more on the way. Even though the W3C says people
shouldn't rely upon stuff in Candidate Recommendations because they
might not be fully cooked yet, I say go for it. Role works
and it can't hurt. RDFa works well, and is processed by
popular search engines like Google and Bing. Telling the
browser (and any Assistive Technologies that might be looking at
the browser) what the role of the various parts of your web page
isn't just polite, it might help someone use your site more
effectively!
|
![[RDF Data]](/fct/images/sw-rdf-blue.png)
![[cxml]](/fct/images/cxml_doc.png)
![[csv]](/fct/images/csv_doc.png)
![[text]](/fct/images/ntriples_doc.png)
![[turtle]](/fct/images/n3turtle_doc.png)
![[ld+json]](/fct/images/jsonld_doc.png)
![[rdf+json]](/fct/images/json_doc.png)
![[rdf+xml]](/fct/images/xml_doc.png)
![[atom+xml]](/fct/images/atom_doc.png)
![[html]](/fct/images/html_doc.png)