Re: State and Status of WAI-ARIA approach to host-language embedding

Henry,

The TAG needs to give this up. The team has proven to you their problems
with the ":".

1. There is not a high cost to authors for doing aria-.

Every major browser manufacturer is on board for this as are some of the
major web tool developers:

http://developer.mozilla.org/en/docs/ARIA:_Accessible_Rich_Internet_Applications/Relationship_to_HTML_FAQ#Who_supports_ARIA.3F

Although not included in this list I am seeing indications on Webkit.org
that work is starting for Safari.

Not a single person has complained about aria- except a couple people like
yourself on the tag.

2. We have support going in from all the major AT vendors and support for
aria- is going into roughly 30 IBM products.

3.   To address your comment about styling:  It is very important that we
be able to use CSS attribute selectors consistently across browsers. The
styling requirement is being able to replace a pile of javascript with CSS
attribute selectors which are tied to ARIA properties is a huge plus. This
is why this feature was added to CSS. WAI-ARIA states and properties are
indicative of information that is often rendered in some form on the
display - Checked, expanded, etc. There is no reason to store this
information in more than one place. Tie CSS attribute selectors to what is
already required for accessibility is a huge plus.

4. I aired the following concerns in Venice and apparently they have not
made their way up to the TAG and higher W3C management. So, I am going to
air them now as this is indicative of a bigger problem in the W3C.

We have been working on WAI-ARIA for four years now. We were on a track to
use namespaced attributes based on our work with the previous HTML working
group. Last year W3C management brought in the WhatWG effort to I assume be
better aligned with the browser manufacturers. This group and me personally
(I was in the older HTML working group) has caused a 6-7 month battle over
the use of a colon, a dash, or an underscore as a
delimiter. The end result was broad industry acceptance of an hyphenated
aria property. For the reasons that Henry and Simon have more than
adequately articulated the use of a colon as a delimiter will not suffice.
There are two many companies that require the use of IE 6 and this will
continue for at least another 2-3 years.

So, my comment to Tim and others who brought the browser manufactures in to
form the new HTML working group: If your intention was to better align our
work with what is delivered in the browser you succeeded. That said, you
have to be willing to make the same adjustments that the rest of the W3C
members have had to deal with and that is we have to make accommodations
for the existing web and that includes the existing legacy browser
situation. Doing otherwise is sending an inconsistent message to W3C
members.

The accessibility effort has been kicked around enough by this vacillating.
The PF Working group, browser manufactures, AT developers, tools developers
have come to a point that meets what the industry needs and will accept.
Furthermore, because of the WAI-ARIA work new developer guidelines for U.S
Public Law 508 of the Rehabilitation Act, WCAG 2, etc. have come to the
point where web and software accessibility requirements are in complete
alignment. I have been working in accessibility at IBM since 1990. WAI-ARIA
is the most important advancement in accessibility in the last ten years
and it is in large part due to the efforts made by all the people involved
here.

This said, we have a very serious problem today. The web is dynamic and
without WAI-ARIA people with disabilities are losing access to the web at
an alarming rate. When Henry says we need to move on to "real problems" he
is stating that we have bigger problems in the areas of mashup
accessibility, complex visualization, SVG accessibility, continued ARIA
adoption, and access to custom RIA componentry. Instead we are wasting
precious resources arguing over the use of a ":" when the industry has
already adopted aria- as a convention and after we have already spent 7
months arguing the case.

I was also a big supporter of using the ":" and namespaces at one time and
given the reality of the web today I have changed that position. I have
nothing but the utmost respect for the TAG but I implore you to let this go
and while this may sound very melodramatic the fact of the matter is that
people's ability to work and use the web are at risk every day we wait.


Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
Chair, IBM Accessibility Architecture Review  Board
blog: http://www.ibm.com/developerworks/blogs/page/schwer


                                                                           
             ht@inf.ed.ac.uk                                               
             (Henry S.                                                     
             Thompson)                                                  To 
             Sent by:                  "Anne van Kesteren"                 
             w3c-wai-pf-reques         <annevk@opera.com>                  
             t@w3.org                                                   cc 
                                       "Michael Cooper" <cooper@w3.org>,   
                                       "Al Gilman"                         
             04/18/2008 03:13          <Alfred.S.Gilman@ieee.org>, "Dan    
             AM                        Connolly" <connolly@w3.org>, "Tim   
                                       Berners-Lee" <timbl@w3.org>, "TAG   
                                       List" <www-tag@w3.org>, "Judy       
                                       Brewer" <jbrewer@w3.org>, "W3C      
                                       WAI-PFWG" <w3c-wai-pf@w3.org>       
                                                                   Subject 
                                       Re: State and Status of WAI-ARIA    
                                       approach to host-language embedding 
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anne van Kesteren writes:

> Your solution also doesn't solve any of the problems:
>
>  * Authors cannot use setAttribute() and getAttribute(). Instead they
> have  to write a set of custom methods. This gives increased authoring
> cost.

I have said several times there is a cost.  It's a small cost.  The
proposed aria- alternative has a cost for authors too.  I think it's a
high cost, and it affects _all_ ARIA users, not just those writing
script.

>  * Authors cannot style these attributes properly accross clients.

Is there any styling requirement for these attributes?  Suppose IE8
supported [aria\:...] selectors, would that make a difference to you?

>  * If at some point in the future we want to give meaning to the colon
> in  HTML5 we couldn't do it because this solution for ARIA would be
> broken by  such a decision.

Not at all -- it's a forward-compatible solution.

>  * This solution introduces two different sets of attributes rather
> than  one. I don't think that's architecturally sound and I think it
> will be  confusing for authors trying to switch from HTML to XHTML. (I
> don't expect  people to use the abstract methods they have to make
> themselves.)

I don't understand -- it specifically introduces _one_ set of
attributes, namely aria:..., instead of two, i.e. aria-... and aria:...

>  * This solution would violate several HTML design principles[1] as
> well.  Most importantly "DOM Consistency", but also "Degrade
> Gracefully",

I disagree -- it precisely provides for graceful degradation

> "Evolution Not Revolution",

You'll have to explain how.

> "Solve Real Problems",

Sure seems to me to solve the problem at hand, without introducing new
ones

> "Priority of  Constituencies",

Again, explain please.

> and "Avoid Needless Complexity".

Two sets of attributes, with complex "when to use which" rules, are
simpler than one?

ht
- --
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged
spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFICFhFkjnJixAXWBoRAgP/AJ9kjA72XG2UK/UZ7n0kgE/TtIr5fACffvtv
8P5l9JH5SGjtwd7peQcWyfA=
=bJEs
-----END PGP SIGNATURE-----