Re: ARIA States and Properties Meeting

This is not true. An AT access ARIA information via the DOM - like Firevox.
It is much easier if access is through the platform accessibility API.


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


                                                                           
             "T.V Raman"                                                   
             <raman@google.com                                             
             >                                                          To 
             Sent by:                  annevk@opera.com                    
             public-html-reque                                          cc 
             st@w3.org                 forums@david-woolley.me.uk,         
                                       www-svg@w3.org, public-html@w3.org, 
                                       public-xhtml2@w3.org,               
             10/30/2007 05:38          w3c-wai-pf@w3.org,                  
             PM                        w3c-html-cg@w3.org                  
                                                                   Subject 
                                       Re: ARIA States and Properties      
                                       Meeting                             
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





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.