W3C home > Mailing lists > Public > public-html@w3.org > November 2007

Re: ARIA States and Properties Meeting

From: Aaron M Leventhal <aleventh@us.ibm.com>
Date: Thu, 1 Nov 2007 10:35:05 -0400
To: David Poehlman <poehlman1@comcast.net>
Cc: annevk@opera.com, forums@david-woolley.me.uk, public-html@w3.org, public-xhtml2@w3.org, "T.V Raman" <raman@google.com>, w3c-html-cg@w3.org, w3c-wai-pf@w3.org, w3c-wai-pf-request@w3.org, www-svg@w3.org
Message-ID: <OFAC3936F8.6C0EFE8D-ON85257386.004FF125-85257386.00501EA9@us.ibm.com>
These assertions need clarification:

ARIA can be made accessible without any changes from the browser, if there 
is an AT that reads the DOM (such as Fire Vox).

In addition, when the browser does implement ARIA support, the AT does not 
need to make changes to get most of the ARIA widgets working -- they don't 
see the difference between a desktop widget and the ARIA widget.
This is why the ARIA support as far back as Firefox 1.5 + Window-Eyes 5.5 
was pretty good.

- Aaron





David Poehlman <poehlman1@comcast.net> 
Sent by: w3c-wai-pf-request@w3.org
10/31/2007 11:50 AM

To
"T.V Raman" <raman@google.com>
cc
annevk@opera.com, forums@david-woolley.me.uk, www-svg@w3.org, 
public-html@w3.org, public-xhtml2@w3.org, w3c-wai-pf@w3.org, 
w3c-html-cg@w3.org
Subject
Re: ARIA States and Properties Meeting







and indeed the at has to be enhanced as well.

On Oct 30, 2007, at 6:38 PM, T.V Raman wrote:

>
> Actually ARIA cannot be used in a browser that hasn't been
> enhanced for it.
>
> ARIA helps the AT *only* when the browser has been enhanced to
> react to the presence of ARIA properties and raise the relevant
> events in response.
>
> You can prove this to yourself by taking an un-ARIA enhanced
> browser like Opera or  IE, loading an ARIA-enhanced document, and
> verifying that it makes *no* difference to any supporting AT.
>
> Anne van Kesteren writes:
>>
>> On Wed, 24 Oct 2007 09:02:03 +0200, David Woolley
>> <forums@david-woolley.me.uk> wrote:
>>> Richard Schwerdtfeger wrote:
>>>> 2. Colon is not an option for text/html
>>>> We cannot use the colon instead of a hyphen, because a colon in
>>>> attribute names causes problems in IE. For example, you cannot 
>>>> use CSS
>>>
>>> Interestingly, though, IE is the strongest precedent for using : 
>>> as as
>>> namespace separator in documents served as text/html.  It is used 
>>> for
>>> VML and for the Microsoft Office supplementary markup.
>>
>> Which is why it's a good reason to not overload that even more with
>> something that would work differently. Also, the idea of ARIA is 
>> that it
>> can be used in existing content without the need for browsers to 
>> implement
>> enhancements. Introducing a namespaced syntax in HTML defeats that
>> requirement.
>>
>>
>>>> attribute selectors in IE when using a colon in the attribute 
>>>> name. Use
>>>
>>> Firstly, I don't actually see complaints that VML and Office 
>>> markup is
>>> causing a problem in this respect, but also, I was under the 
>>> impression
>>> that IE still didn't have strong support for attribute value based
>>> selectors (I've not seen them used in mainstream web site CSS), 
>>> which I
>>> would have thought would be necessary for ARIA attributes to be 
>>> useful
>>> in CSS.  It could be an issue for scripting.
>>
>> They work fine in my copy of Internet Explorer 7. (Well, except for 
>> the
>> noted issue with colons.)
>>
>>
>>>> *6. Currently proposed solutions for ARIA states and properties 
>>>> (not
>>>> role)*
>>>> A. Use hyphenated property everywhere .
>>>
>>> This means that either ARIA attributes have to be part of the core 
>>> of
>>> XHTML, SVG, etc., or that you have the ugly situation of having two
>>> different syntaxes for namespacing co-exist, one of which is only
>>> available to official standards, because it cannot guarantee global
>>> uniqueness otherwise.
>>
>> We don't want to introduce namespacing in the Namespaces in XML 
>> sense, see
>> above. Using the same syntax in a controlled set of languages seem 
>> fine.
>> If there's ever a need for a more "global" syntax that can be 
>> introduced
>> when the problem arises.
>>
>>
>>>> D. For long term consideration: Should the W3C consider create a
>>>> collection of cross-cutting attributes which may be used across
>>>> renderable markup languages without namespaces. e.g. (Role, ARIA,
>>>> RDF/A, etc.)
>>
>> I don't think we should make this anymore generic than it is. If we 
>> keep
>> it consistent with naming in HTML and SVG all should be fine.
>>
>>
>>> For the long term, shouldn't one be assuming that text/html browsers
>>> will support XML namespace notation in CSS; the major one already
>>> supports it in the HTML.  (Or that the world will move to XML - 
>>> although
>>> it is looking less and less likely that that will happen.)
>>
>> This doesn't fit in the requirements of ARIA, as far as I can tell. 
>> I'm
>> also not sure what XML namespace notation support in CSS would help 
>> here
>> as HTML doesn't support namespaces.
>>
>>
>> -- 
>> Anne van Kesteren
>> <http://annevankesteren.nl/>
>> <http://www.opera.com/>
>
> -- 
> Best Regards,
> --raman
>
> Title:  Research Scientist
> Email:  raman@google.com
> WWW:    http://emacspeak.sf.net/raman/
> Google: tv+raman
> GTalk:  raman@google.com, tv.raman.tv@gmail.com
> PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
>
>
Received on Thursday, 1 November 2007 14:36:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:09 GMT