Re[2]: [1.2T LC] @aria-foo atributes: un-prefixed, forbidden? (ISSUE-2090)

** epilogue:

We discussed this on today's WAI-ARIA working session and the Group
agrees with me that I should accept this disposition.

http://www.w3.org/2008/10/13-pf-minutes.html#item05

So yes, I accept this disposition of my comment.

** summary:

After considering your reasoning, I differ on details but can't
say you must change.  If SVG wants to defer implementing WAI-ARIA
until it can be done in definitive detail in the join schema,
we can't and shouldn't try to stop you.

The only question is if this creates a missed opportunity for
operational use of SVG+ARIA in a somewhat shorter term.  If
implementation of ARIA in SVG processors is not imminent anyway,
it is largely of academic concern.

I still want to review this issue with the PFWG; but here are my
personal thoughts in the interest of your having some gestation
(sleep on it) time.

** details inline

On 9 Oct 2008, at 3:14 AM, Doug Schepers wrote:

> Hi, Al-
>
> You're correct that the SVG 1.2 Tiny spec, by itself, does not  
> allow the
> unprefixed aria-* attributes on elements (though prefixed attributes
> would still work, since they fall out of the XML Namespaces model
> already integrated into SVG).
>
> The SVG WG did consider this seriously over the course of multiple
> conversations, and there are several reasons that we didn't include
> support for the unprefixed ARIA attributes to this spec:
>
> 1) The WAI-ARIA spec is not yet stable, so we could not normatively
> reference it.
>
> 2) The "aria-*" syntax, though implemented in some browsers, is not  
> yet
> part of the HTML5 spec; since that spec is the sole reason for the
> exceptional syntax, it seemed imprudent for us to add it, in case a
> future incompatibility arose later.

Forget HTML5, that's a misinterpretation of our reasons.  To deal
with HTML at all without a major wait we needed to use the aria-*
approach.  And HTML is the bulk of our market.  But if
SVG feels conservative, and doesn't want to create a placeholder
now on the chance that WAI-ARIA won't fit the placeholder by the
time it is done, that is your prerogative.

> 3) The RelaxNG schema would need to be developed (I've seen Henri
> Sivonen's schema for HTML5 [1], and I think that SVG's would be much
> simpler, but we haven't had time to look into all the details,
> especially any gotchas that might arise).

You don't need a schema that *requires correct* ARIA markup to include
in the schema a loophole that *permits correct* ARIA markup.

> 4) Most importantly, we don't have 2 conforming SVG 1.2 Tiny
> implementations of that syntax that we can reference in our
> Implementation Matrix,

I don't know that you don't.

If, as you say later, the attributes show up in the DOM anyway,
then you *do* have two conforming implementations already.  That's
the only proposed change: that the specification allow the
aria-* attributes to be present and flow through to the DOM.

Don't consider it an SVG extension; consider it a co-format.

> and we cannot afford to wait for them (especially
> since ARIA itself is not yet done, and we don't know what changes  
> might
> happen in the future).

Absolutely.  We don't want to force any changes that would
invalidate your existing Implementation Report results.
>
> We did add the 'role' attribute because it has a general use beyond  
> ARIA
> that we could justify, and the implementation burden was very low.  We
> took this step to lay the groundwork for future accessibility
> development, and to demonstrate our good faith in committing to
> integrating ARIA into SVG.
>
> Our intent, as we stated before [2], is to work with WAI to develop a
> separate module that integrates ARIA with SVG more completely,  
> including
> a set of roles for SVG diagrams.  The RelaxNG schema would belong in
> this spec.

We have so far contemplated your doing this in two steps, implementing
WAI-ARIA 1.0 without diagram roles first and later we extend to include
diagram roles.

A schema for the former can be produced as soon as WAI-ARIA and
SVG 1.2 Core are available in semi-stable drafts.  We are considering
creating a generator that can, using the markup conventions in the  
WAI-ARIA
specification document, automatically create a RELAX-NG schema for  
the ARIA
part from the document.  This could be tweaked to generate a module that
integrates into an SVG driver.

> In the meantime, nothing stops an author from using ARIA with SVG
> (assuming there are implementations that support it).

Other than the provisions of the specification document.

> Any aria-*
> attributes, and their values, would still be present in the DOM; the
> only issue is that the document would not validate against the SVG 1.2
> Tiny schema.

It would not validate against the spec, by any correct checker
that follows the spec.

> When we have developed a new schema that does include ARIA
> support, such documents could be validated against that schema, and  
> such
> an extended schema will not conflict with existing SVG specs.

I think I differ with you there.  Documents that conform to the
new schema would still violate SVG 1.2T, so far as I can see.

> In fact,
> it would be good for authors to at least experiment along these lines,
> to ensure that we have our bases covered before finalizing  
> something in
> a spec.
>
> I hope that this explains the situation and allays your concerns.
> Please do let us know promptly either way.

I plan to review this issue with the Working Group on Monday.  Get
back to you then.

I think that the true decision factors have yet to be mentioned.

Is there any use of SVG+script to create interactive web applications
today?  What fraction of the total SVG usage does this represent?
Do these applications deliver any sort of accessibility already?

Questions like these would determine the urgency of having WAI-ARIA
be legal in SVG 1.2T.

If this sort of web application is rare, and SVG processor
implementation of WAI-ARIA is going to wait until there is a
normative SVG module implementing WAI-ARIA into SVG, then
the invalid nature of experimental documents is only to be
expected, and you may proceed without it being a significant
defect.

But if there are SVG Web Applications that take their interactive
behavior from scripting, and look and feel like desktop widgets
that appear in installed software applications, we should see
if your current applications are still complete implementations
of a spec with a more permissive attitude to aria-* attribute
names.

Al
> [1]
> http://lists.w3.org/Archives/Public/public-schemata-users/2008May/ 
> 0001.html
> [2] http://lists.w3.org/Archives/Public/www-svg/2008Jun/0040.html
>
> Regards-
> -Doug
>
> Al Gilman wrote (on 10/1/08 3:02 PM):
>>
>> ** problems statement
>>
>> <quote
>>
>> Unprefixed attributes on elements in the SVG namespace must not be  
>> used
>> for extensions.
>>
>> </quote>
>>
>> But that's exactly what WAI-ARIA asks host languages to allow;  
>> that the
>> aria-foo attributes appear un-prefixed:
>>
>> <quote
>>
>> The names of these attributes do not have a prefix set off by a  
>> colon;
>> in the terms of Namespaces they are "unprefixed attribute names."
>>
>> </quote>
>>
>> When I ran our approach through the Hypertext CG, I believe the  
>> feedback
>> I got was that your group had reviewed this and were willing to live
>> with the un-prefixed, aria-foo attribute names for the WAI-ARIA  
>> states
>> and properties.
>>
>> So I hope that this is just a matter of incomplete editing, not a  
>> latent
>> disagreement about the host language embedding approach for ARIA.
>

Received on Monday, 13 October 2008 20:10:27 UTC