[Bug 10449] Consider allowing various command-like ARIA roles for h1-h6

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10449





--- Comment #9 from Rich Schwerdtfeger <schwer@us.ibm.com>  2010-09-21 18:52:24 ---
While I appreciate that an HTML header has strong native semantics, the
specification allows a header to:

- be placed in the tab navigation order
- be styled
- Have children
- apply script

It can do all this without requiring any implicit state information like an
interactive form element. If a header has such strong native semantics then why
would all this additional functionality be required?

In fact, an author could in fact use script in response to user to write
anything it wants dynamically between the header tags. In other words it could
write to it as if it were a live region or even to produce an interactive
widget.

Another gaping hole in the HTML spec. left over from HTML 4 is the fact that
the heading level is not enforced by document structure. An author could stick
an H2 anywhere in the document and follow it by an H1. This has allowed authors
to use headers for styling content wherever they please. What should have been
done is eliminate the HX tags altogether and created a single header tag whose
level is determined by the browser DOM containment model. That would have much
stronger native semantics and force the author to design their documents
better. Unfortunately, the cat is out of the bag and we are stuck with it. This
has plagued people with disabilities for the longest time as header navigation
only works when people use it as a best practice.

Since it does not have any implicit state information an author could easily
override the element and apply ARIA semantics without causing a conflict in
state information provided to the assistive technology. 

I would argue that although a header is intended semantics if used properly,
yet the specification has opened the doors for an author to use it improperly.
These additional interactive tools (script, CSS, etc.) allow the author to
manipulate headers in a fashion that dilutes the host language semantics of a
header and allows the author to turn it into something entirely different.

It is for these reasons that we need to apply ARIA role semantics to headers.

In the editor's example - a couple basic headers there is no reason to apply
ARIA role semantics to that situation and frankly there would be nothing that
would compel the author to do so. It would require additional work that is
unnecessary. 

In this scenario:

<h1><span role="button">foo</span></h1>

The author is not applying a role of button to a header. It is being applied to
as span within a header. 

However, this example:

<h1 onclick='alert("<h1> onclick!")'>Click to test.</h1>

shown on this web site:

http://dev.opera.com/forums/topic/165324

should have had a role of button. A screen reader looking at this would
immediately know the <h1> was interactive if the role was button. 

In no way did this act as a heading as was intended by the spec. nor was it a
link.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Tuesday, 21 September 2010 18:52:26 UTC