W3C home > Mailing lists > Public > public-html@w3.org > February 2008

Re: ISSUE-35 (aria-processing): Need to define processing requirements for aria states and properties when used in html [HTML 5 spec]

From: Simon Pieters <simonp@opera.com>
Date: Thu, 21 Feb 2008 19:00:59 +0100
To: "Gregory J. Rosmaita" <oedipus@hicom.net>, "HTML Issue Tracking WG" <public-html@w3.org>
Cc: "Al Gilman" <Alfred.S.Gilman@ieee.org>
Message-ID: <op.t6vyzxwjidj3kv@hp-a0a83fcd39d2.belkin>

On Thu, 21 Feb 2008 18:24:52 +0100, Gregory J. Rosmaita  
<oedipus@hicom.net> wrote:

>
> this "issue" represents a fundamental mis-understanding of the point of
> ARIA markup and the PFWG's attempts to work with the HTML WG

I think you're missing the point of this issue.


> -- as stated
> by Al Gilman in a post to public-html
>
> <q
> cite="http://lists.w3.org/Archives/Public/public-html/2007Jul/0903.html">
> The working group likes the idea of having built in semantics in HTML and
> in particular would prefer to have common document elements, such as
> widgets built in to the markup. This reduces download size and the effort
> required to make a web page accessible. For these reasons, we would
> promote the use of such markup over the ARIA approach. That said, we do
> believe that HTML 5 will not incorporate document elements for all those
> included in the ARIA role taxonomy nor will it include all the states and
> properties. For these reasons, backward compatability for the ARIA
> specifications is a must.
> </q>
>
> further on in his email, Al Gilman also states:
>
> <q
> cite="http://lists.w3.org/Archives/Public/public-html/2007Jul/0903.html">
> To summarize, our goals for HTML 5 are as follow:
>
>     * Support for issues highlighted in Table: 1 of the ARIA Roadmap
>     * Backward compatability to ARIA, including the role attribute.
>     * Allow for full interoperability with assistive technologies
>     * A preference for access to accessibility information via the DOM
>     * Reduced efforts by authors to support assistive technologies
>     * Support for the access element or a version of it.
>     * Maintain equivalent or improved accessibility features of HTML 4.01
> </q>
>
> i vote that this is a NON-ISSUE as,

This is not about voting.


> but would support re-opening it
> WITHOUT the following verbiage:
>
> <q
> cite="http://www.w3.org/html/wg/tracker/issues/35">
> It also requires consideration of how aria
> features interact with html-native features and, where
> functionality is duplicated, consideration of whether the
> advantages of having more than one way to achieve the same
> effect outweighs the cost.
> </q>

Let's pretend that the issue is about HTML4 instead of about HTML5. How  
does ARIA integrate with HTML4? Are the duplicated features really needed?  
This is not about backwards compatibility or providing the features, it's  
about how UAs are actually supposed to implement it.

Example: HTML4 has <h1> through <h6> elements to create sections and  
headings. ARIA has role="section" and role="heading". How do they  
integrate? How does a UA create the document outline? Does role="heading"  
actually solve a problem when HTML is the host language?

-- 
Simon Pieters
Opera Software
Received on Thursday, 21 February 2008 18:01:27 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:52 UTC