state must control appearance [was: Re: State and Status of WAI-ARIA approach...]

  I just want to re-emphasize one point:

>>
>>>
>>> On 18 Apr 2008, at 9:09 AM, Simon Pieters wrote:
>>>>
>>>>
>>>> On Thu, 17 Apr 2008 18:04:00 +0200, Henry S. Thompson  
>>>> <ht@inf.ed.ac.uk> wrote:
>>>>
[...]

>> Agreed.  But I doubt seriously that there will _be_ many aria/css
>> rulesets.  My understanding was that the ARIA use cases are primarily
>> AJAX-oriented, so the DOM access issues are the important ones.
>
> Styling is important for ARIA states.
>

I feel I need to upgrade that.  Styling is essential for ARIA states.

What the designer cares about is the way the appearance tracks the
and cues the user interaction.

ARIA is predicated on getting the accessibility API and the appearance
in sync.  The strategy is to have both driven off the same state, which
is in the DOM.  The assistive technology needs the state and event  
information
that matches the appearance so that it can appropriately track and cue
the user interaction in the alternate presentation it manages.

If the information path from the ARIA state to the appearance is
not rock-solid and cross-browser, the designers will reject the ARIA
widgets and we will be back where we started.

Al



>>
>>>
>>> On 18 Apr 2008, at 9:09 AM, Simon Pieters wrote:
>>>>
>>>>
>>>> On Thu, 17 Apr 2008 18:04:00 +0200, Henry S. Thompson  
>>>> <ht@inf.ed.ac.uk> wrote:
>>>>
>>> It's not really clear to me what it is that you discovered. It seems
>>> to me  that you have tried to work around the differences that the
>>> colon imposes  and thus demonstrated that different code paths is
>>> needed.
>>
>> I did that as well, but what I was referring to was the "Script did
>> not run" reports against Firefox, which had nothing to do with :
>> vs. -.
>
> Ok.
>
>
>>> Using the colon means that UAs and authors have to support two  
>>> sets of
>>> ARIA attributes -- one set of namespaced attributes, and one set of
>>> no-namespace attributes with colons in their local names.
>>
>> How so?  The whole point of my exploration is that a _single_ entry
>> point (in my examples, spelled 'getARIAttribute'), can be used in all
>> contexts.
>
> But getARIAttribute uses different code paths for if it thinks the  
> document is an XML document or an HTML document, with different  
> checks for Firefox and for Opera and gets it wrong in Safari.
>
> getAttribute('aria-foo') is also a single entry point and works  
> everywhere.
>
>
>>> Having aliases is an indicator of bad design.
>>
>> Exactly -- having aria-role and aria:role as aliases is bad design.
>
> Yes. That's why browsers only support the former.
>
>
>> Seriously, we are stuck with a complex legacy, and _any_ resolution
>> has crufty aspects.  The question is, which cruft is preferable.
>>
>>> Moreover, it will be seriously error prone for authors, since
>>> attributes from either set can appear on the same node in both HTML
>>> and XML documents:
>>>
>>> Case 1: HTML document:
>>>
>>>    <div a:foo='true'>
>>>
>>>    div.setAttributeNS('http://www.w3.org/2005/07/aaa', 'foo',  
>>> 'false');
>>>
>>> Case 2: XHTML document:
>>>
>>>    <div a:foo='true'>
>>>
>>>    div.setAttribute('a:foo', 'false');
>>>
>>> Case 3: either HTML or XHTML document:
>>>
>>>    <div>
>>>
>>>    div.setAttributeNS('http://www.w3.org/2005/07/aaa', 'foo',  
>>> 'true');
>>>    div.setAttribute('a:foo', 'false');
>>
>> Sorry I didn't make clear in the original post that the cost of my
>> proposal is that you _don't_ use the standard accessors.  You  
>> _always_
>> write
>>
>>     setARIAttribute(div,'foo','true')
>
> You could end up with both attributes despite using  
> setARIAttribute, e.g. if you copy an element from an HTML document  
> to an XML document in the DOM or you insert a DOM fragment parsed  
> from XML into an HTML document.
>
>
>
>>> It fails in Safari because your "XML" check is actually bogus:
>>
>> Do you mean there _is_ no test in Safari which will correctly
>> distinguish an HTML from an XML parse?
>
> I'm sure there are ways to do so, but you shouldn't have to. You  
> should be able to work with the DOM the same in both cases.
>
>
>> That _would_ be a problem. .
>>
>>> Per HTML 5, elements that are inserted in the document by the HTML
>>> parser  are put in the XHTML namespace, and hence, you get the "XML"
>>> codepath for  HTML documents in UAs that follow HTML 5.
>>
>> Are you suggesting that Safari is already implementing HTML 5 rules?
>
> Yes.
>
>
>>> No matter how you try to spin it, even if you get the "XML" check
>>> right, a  node can have both attributes set at the same time
>>
>> Not if you just use the uniform getter/setter.
>
> Yes you can (see above).
>
>
>>> The right way to solve this is to only have one set of attributes
>>
>> For sure.
>
> Good that we agree on this point. :-)
>
>
>>> and that means not using the colon (given the constraints that we
>>> can't change the HTML parser, nor the XML parser, nor DOM Core, and
>>> that it should work the same in existing browsers).
>>
>> Or using a setter/getter pair which use the appropriate single
>> attribute in each case.
>>
>>>> CSS selection succeeded everywhere except IE,
>>>> where it failed across the board -- I presume this could be  
>>>> fixed for
>>>> IE8, given what I understand, but again I didn't have access to a
>>>> suitable IE8 installation.
>>>
>>>     p[a\:foo], p[a|foo] { background:lime }
>>>
>>> IE doesn't support namespaces in CSS, and so, the entire ruleset is
>>> dropped. However, even if you did:
>>>
>>>     p[a\:foo] { background:lime }
>>>     p[a|foo] { background:lime }
>>>
>>> ...IE7 wouldn't apply the first ruleset because attribute selectors
>>> with  colons don't work in IE7. (Attribute selectors without colon
>>> work fine in  IE7.) But, even if attribute selectors with colon did
>>> work in IE7, you'd  still have to duplicate all your ARIA  
>>> rulesets in
>>> CSS, and that's bad  compared to not having to do so:
>>>
>>>     p[aria-foo] { background:lime }
>>
>> Agreed.  But I doubt seriously that there will _be_ many aria/css
>> rulesets.  My understanding was that the ARIA use cases are primarily
>> AJAX-oriented, so the DOM access issues are the important ones.
>
> Styling is important for ARIA states.
>
>
>>> I think we can't come to useful conclusions from your script  
>>> since it
>>> doesn't work correctly in UAs that implement HTML 5
>>
>> Please clarify which browsers those are,
>
> All browsers in due course, when they implement HTML 5.
>
>
>> and why it _can't_ work in
>> them.
>
> Well, if an element is in the XHTML namespace, .namespaceURI is  
> truthy ("http://www.w3.org/1999/xhtml") instead of falsy (null),  
> and hence you get the "XML" codepath in your function.
>
>
>> I also note that HTML 5 is not baked yet. . .
>
> The reason HTML 5 says that elements created by the HTML parser be  
> put in the XHTML namespace is precisely to satisfy the DOM  
> Consistency principle. The DOM you get from parsing text/html and  
> the DOM you get from parsing XML are effectively the same so that  
> authors can use the same scripts and stylesheets for either without  
> using different codepaths and selectors.
>
>
>>> nor does it cover the case when an element has both attributes at
>>> the same time.
>>
>> I addressed this point above.
>>
>>> However, even ignoring that, 16 lines of code and the resulting
>>> indirection elsewhere in the code is bad compared to no additional
>>> 16 lines of code and no indirection elsewhere in the code.
>>
>> For sure.  And using aria- in some documents and aria: in others is
>> compared to using aria: everywhere is bad too.
>
> Using both aria- and namespaced attributes is bad, indeed.
>
> -- 
> Simon Pieters
> Opera Software
>

Received on Friday, 18 April 2008 15:12:02 UTC