Re: Document conformance: Integrating ARIA into HTML5

I only have a superficial understanding of ARIA, but everything
explained here makes perfect sense (to me) for document conformance.

I wonder if where "ajax libraries" are mentioned, that may refer more
generally to authoring tools? There are a number of tools -- content
management systems and application frameworks spring to mind -- that I
would also place in the same category: using classes to reinvent
semantics that exist readily in HTML. Class names containing 'label'
and 'heading' being classic examples. I can imagine such tools using
aria attributes to claim greater quality, rather than using HTML
appropriately. Conformance checking around this sounds very useful.

I also support the concept that HTML5 specifies some aria mappings (to
save authors from specifying the obvious?) ... e.g. a checkbox is a
checkbox, using the HTML markup for checkboxes is enough without
adding aria markup to (redundantly) define a checkbox is a checkbox.
This would in turn prevent any effort to specify a checkbox is a radio
button. ("Prevent" is probably too strong a term, but it would make it
'non conforming' ?)

I wholeheartedly agree with any approach that removes redundancy and
strengthens the consistency and accessibility of markup by default,
and helps reduce the spurious repurposing of markup in confusing and
counter-intuitive ways. That's got my vote.

Correct me if I misunderstood anything.

cheers
Ben


On Mon, Mar 24, 2008 at 11:26 PM, Henri Sivonen <hsivonen@iki.fi> wrote:
>
>  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.
>  progressbar)
>     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
>  above)
>
>   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
>  role.)
>
>   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:
>  http://hsivonen.iki.fi/aria-html5/
>
>  --
>  Henri Sivonen
>  hsivonen@iki.fi
>  http://hsivonen.iki.fi/
>
>
>
>

Received on Tuesday, 25 March 2008 03:34:56 UTC