W3C home > Mailing lists > Public > public-pfwg-comments@w3.org > January to March 2008

Document conformance: Integrating ARIA into HTML5

From: Henri Sivonen <hsivonen@iki.fi>
Date: Mon, 24 Mar 2008 15:26:41 +0200
Message-Id: <B451AA91-F179-406C-AEDD-F65C08CA47C5@iki.fi>
To: public-pfwg-comments@w3.org, HTML WG <public-html@w3.org>

I'm implementing conformance checking for ARIA in HTML5. (I know HTML  
5 doesn't reference ARIA yet--I'm hoping to get a feedback loop going.)

This email is about requirements on document conformance--*not* about  
browser conformance. (Specifically, this email does not suggest  
changing the "ARIA always overrides" browser implementation policy.)

First, some observations:
  * It's really quite unfortunate that ARIA was developed separately  
from HTML5. In an ideal design, the functionality of ARIA would be  
natively present in HTML5. It's too late to change that, but there is  
a chance try to fit them together a bit more nicely.

  * From an HTML point of view, ARIA defines four kinds of roles:
    1) roles that HTML5 does not have natively (e.g. tabpanel)
    2) roles that HTML5 has natively but HTML4 didn't have (e.g.  
    3) roles that HTML4 has natively but that Ajax libraries still  
reimplement for styling reasons (e.g. radio)
    4) roles that HTML4 has natively and that Ajax libraries have  
absolutely no legitimate styling reason to reimplement (e.g. heading,  
columnheader and table)

  * I think roles in group #4 should be non-conforming in HTML and  
should be left for host languages with weaker native semantics, such  
as SVG.

  * In the cases of #1, #2 and #3, there may be ARIA states and  
properties that HTML doesn't have natively. In those cases, I think it  
should be permissible to use states or properties that make sense with  
the native role of an HTML element without redeclaring the native role  
using the role attribute. For example, aria-sort should be allowed on  
a <th> without a role attribute and aria-controls should be allowed on  
an <input type=button> without a role attribute. Moreover, many HTML  
elements have a native role that is region or its subrole.

  * When an element has a strong native semantic, it seems just wrong  
to override it. Consider <input type=radio role=checkbox>

  * There are elements on which ARIA, frankly, makes no sense.  
Consider HTML <param> or SVG <defs>.

Therefore, I suggest the following steps for establishing document  
conformance requirements for ARIA integrated into a host language:

  1) Identify ARIA roles that are patently redundant with the long- 
established native elements of the language. Ban those ARIA roles. (#4  

  2) Identify the closest implicit role of every element in the host  
language (e.g. <input type=radio> has the native implicit role radio).  
Document these so that UA implementors end up exposing the ARIA roles  
and the native roles to AT in a consistent way. For each element with  
a native role, consider which ARIA states and properties are not  
covered natively or are covered natively in the latest language spec  
but aren't covered in legacy deployments. (For example, the input  
element in HTML5 has a 'required' attribute but legacy considerations  
still give a use case for aria-required, since aria-required doesn't  
interact with the actual form submission algorithm.) Allow those  
states and properties on the element without an explicit role attribute.

  3) Identify which elements have strong native roles. Make it non- 
conforming to override those. (For example, <input type=radio>  
probably should be considered to have a strong native role but <li>  
should probably be considered to have a weak and overrideable native  

  4) Identify which elements don't make sense with ARIA (e.g.  
<param>). Make it non-conforming to use ARIA (except global states and  
properties) with those elements.

  5) Enumerate the roles that are applicable on the root element.  
Chances are that most roles aren't.

To get discussion started, I have written a rough first-iteration draft:

Henri Sivonen
Received on Monday, 24 March 2008 13:27:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:45:56 UTC