New draft: ARIA in user agents best practices

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

New draft: ARIA in user agents best practices

Aaron Leventhal-3
Feedback and improvements welcome:

http://developer.mozilla.org/en/docs/ARIA_UA_Best_Practices

- Aaron

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: New draft: ARIA in user agents best practices

David Bolter
Aaron, this is a really nice contribution.

I hope you don't mind I went through and made a bunch of trivial typo fixs:
http://developer.mozilla.org/en/docs/index.php?title=ARIA_UA_Best_Practices&diff=68595&oldid=68568

I have some questions (based on yesterday afternoon's version):

In 11.3.1 you mention "Assistive technologies occasionally will take
control of focus. The user agent needs to allow this."... maybe you
could expand a little here as to why and how.

11.3.1.1
7. "accessibility API hierarchy"... I know what you mean here but I
wonder if it should be rephrased. Perhaps "accessible object hierarchy"?

11.3.1.2 aria-activedescendant
At the end of the second paragraph where you say the author should style
to show focus... should we recommend using :focus here?

#3 "...If aria-activedescendant is cleared or doesn't point to an
element in the current document, then fire a focus event for the object
that had the attribute change." -- I don't understand.

I don't really understand the XXX question at the end of this section.

11.3.6

Near the end of this section you refer to "content subtrees"... I think
I know what this is but perhaps it should be defined? I dunno.

11.3.10

There was a todo about propogating states... but seems to be gone now?
My thoughts were yes they should propogate FWIW.

The phrase: "For simplicity and perf this may trim out", should that be
"For simplicity and performance, trim out..."?

11.3.12

"When a subtree is removed or hidden"... what about "moved"... or is
that just obviously a removal and an insert?

11.3.14

"The user agent can follow focus up to a tabpanel"... I wasn't sure
about this phrasing and tried to think of something better but now I
like it... heh. I'm noting it anyway in case you want to rephrase.  It
was the "follow focus" part I found a bit misleading.


Again, a great document and I can only imagine how easier it will make
things for Webkit if they are going to implement ARIA support!

cheers,

David

Aaron Leventhal wrote:

> Feedback and improvements welcome:
>
> http://developer.mozilla.org/en/docs/ARIA_UA_Best_Practices
>
> - Aaron
>
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility
>  

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: New draft: ARIA in user agents best practices

Aaron Leventhal-3
David Bolter wrote:
> Aaron, this is a really nice contribution.
>
> I hope you don't mind I went through and made a bunch of trivial typo
> fixs:
> http://developer.mozilla.org/en/docs/index.php?title=ARIA_UA_Best_Practices&diff=68595&oldid=68568 
>
Of course not -- as usual :)    Do whatever needs to get done.

> I have some questions (based on yesterday afternoon's version):
>
> In 11.3.1 you mention "Assistive technologies occasionally will take
> control of focus. The user agent needs to allow this."... maybe you
> could expand a little here as to why and how.
Done.
>
> 11.3.1.1
> 7. "accessibility API hierarchy"... I know what you mean here but I
> wonder if it should be rephrased. Perhaps "accessible object hierarchy"?
Done.
>
> 11.3.1.2 aria-activedescendant
> At the end of the second paragraph where you say the author should
> style to show focus... should we recommend using :focus here?
No, since actual focus is on the container. Clarified that -- although
in general this is for browser implementers not authors. There is
another doc being written for that. Have you seen it?
>
> #3 "...If aria-activedescendant is cleared or doesn't point to an
> element in the current document, then fire a focus event for the
> object that had the attribute change." -- I don't understand.
I'm not sure what needs to be said better.
For <div aria-activedescendant="foo1"><span id="foo1">Hi</span><span
id="foo2"></div>.
- If the author changes aria-activedescendant to foo2, the browser needs
to fire a focus event for that object. We already covered that in the
previous sentence.
This new sentence said is the author changes aria-activedescendant to
"", or removes the attribute or sets it to an ID not in this document,
then the browser needs to fire a focus event on the div (that's the
"object that had the attribute change").
Help reword?
>
> I don't really understand the XXX question at the end of this section.
Fine. I'll work on that with Opera.
>
> 11.3.6
>
> Near the end of this section you refer to "content subtrees"... I
> think I know what this is but perhaps it should be defined? I dunno.
This is for browser manufacturers, so everyone knows what that is.
>
> 11.3.10
>
> There was a todo about propogating states... but seems to be gone now?
> My thoughts were yes they should propogate FWIW.
Okay well that makes it more work for Fire Vox, since it's reading the
DOM. I guess there's a reason to do it though. It's still on the PF
issues list.
>
> The phrase: "For simplicity and perf this may trim out", should that
> be "For simplicity and performance, trim out..."?
>
> 11.3.12
Fixed the sentence but kept "may"
>
> "When a subtree is removed or hidden"... what about "moved"... or is
> that just obviously a removal and an insert?
>
> 11.3.14
Good point. Fixed.
> "The user agent can follow focus up to a tabpanel"... I wasn't sure
> about this phrasing and tried to think of something better but now I
> like it... heh. I'm noting it anyway in case you want to rephrase.  It
> was the "follow focus" part I found a bit misleading.

>
>
> Again, a great document and I can only imagine how easier it will make
> things for Webkit if they are going to implement ARIA support!
And hopefully help IE and Opera do something similar that Firefox does.
However, I think we really need the equivalent of the CSS acid test for
ARIA. It's a point of pride to do well in that. It could just test MSAA
for now, which would let us test Opera, Safari and IE. That might be
something we need you guys to do, and I think it fits in with your
grants. What do you think?

>
> cheers,
>
> David
>
> Aaron Leventhal wrote:
>> Feedback and improvements welcome:
>>
>> http://developer.mozilla.org/en/docs/ARIA_UA_Best_Practices
>>
>> - Aaron
>>
>> _______________________________________________
>> dev-accessibility mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-accessibility
>
>
>


_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: New draft: ARIA in user agents best practices

Aaron Leventhal-3
In reply to this post by David Bolter

>
>
> 11.3.14
>
> "The user agent can follow focus up to a tabpanel"... I wasn't sure
> about this phrasing and tried to think of something better but now I
> like it... heh. I'm noting it anyway in case you want to rephrase.  It
> was the "follow focus" part I found a bit misleading.
Fixed as well.



_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: New draft: ARIA in user agents best practices

Charles McCathieNevile-2
In reply to this post by Aaron Leventhal-3
On Thu, 13 Mar 2008 09:26:54 -0700, Aaron Leventhal  
<[hidden email]> wrote:

> David Bolter wrote:
>> Again, a great document and I can only imagine how easier it will make
>> things for Webkit if they are going to implement ARIA support!

> And hopefully help IE and Opera do something similar that Firefox does.
> However, I think we really need the equivalent of the CSS acid test for
> ARIA. It's a point of pride to do well in that. It could just test MSAA
> for now, which would let us test Opera, Safari and IE. That might be
> something we need you guys to do, and I think it fits in with your
> grants. What do you think?

Except that WebKit development is on Mac, no? We (Opera) work across Mac  
and Windows anyway, so having the test work on Mac would be a reasonable  
thing to do.

Aaron, hope to see you today...

cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: New draft: ARIA in user agents best practices

Aaron Leventhal-3
In reply to this post by Aaron Leventhal-3
Yes, ultimately we should test through other APIs like Universal Access
as well. But, right now I don't even know what the ARIA to UA mapping
is! I sure would love to get that info, and Opera is in the best
position to provide that now -- before WebKit starts implementing with
different results.

In general, how much of this cross-browser work like testing and docs
can Opera (and the community as a whole) help with? ... I suspect I'll
hear a lot of silence about now :)

Some commitments would be great. We need help with:
1. The implementors guide -- review and correction --
http://developer.mozilla.org/en/docs/ARIA_UA_Best_Practices
2. The Universal Access mappings
3. Test suites -- perhaps describing correct behavior with various ATs
4. Acid test for MSAA + (IA2?). I don't even know yet what IE is going
to use for the pieces MSAA won't cover. Firefox uses IA2 -- I'm hoping
Opera does the same.
5. Acid test for Universal Access

Beyond testing we'd also like to get more useful feedback on docs such
as the spec itself.

- Aaron

Charles McCathieNevile wrote:

> On Thu, 13 Mar 2008 09:26:54 -0700, Aaron Leventhal
> <[hidden email]> wrote:
>
>> David Bolter wrote:
>>> Again, a great document and I can only imagine how easier it will make
>>> things for Webkit if they are going to implement ARIA support!
>
>> And hopefully help IE and Opera do something similar that Firefox does.
>> However, I think we really need the equivalent of the CSS acid test for
>> ARIA. It's a point of pride to do well in that. It could just test MSAA
>> for now, which would let us test Opera, Safari and IE. That might be
>> something we need you guys to do, and I think it fits in with your
>> grants. What do you think?
>
> Except that WebKit development is on Mac, no? We (Opera) work across Mac
> and Windows anyway, so having the test work on Mac would be a reasonable
> thing to do.
>
> Aaron, hope to see you today...
>
> cheers
>
> Chaals
>

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: New draft: ARIA in user agents best practices

David Bolter
In reply to this post by Aaron Leventhal-3
Hi Aaron,
>> 11.3.1.2 aria-activedescendant
>> At the end of the second paragraph where you say the author should
>> style to show focus... should we recommend using :focus here?
>>    
> No, since actual focus is on the container. Clarified that -- although
> in general this is for browser implementers not authors. There is
> another doc being written for that. Have you seen it?
>  

Not sure. Is it basically the dhtml style guide work?

>> #3 "...If aria-activedescendant is cleared or doesn't point to an
>> element in the current document, then fire a focus event for the
>> object that had the attribute change." -- I don't understand.
>>    
> I'm not sure what needs to be said better.
> For <div aria-activedescendant="foo1"><span id="foo1">Hi</span><span
> id="foo2"></div>.
> - If the author changes aria-activedescendant to foo2, the browser needs
> to fire a focus event for that object. We already covered that in the
> previous sentence.
> This new sentence said is the author changes aria-activedescendant to
> "", or removes the attribute or sets it to an ID not in this document,
> then the browser needs to fire a focus event on the div (that's the
> "object that had the attribute change").
> Help reword?

OK, not a big deal :)  If I think of something better I'll let you know.

>> Again, a great document and I can only imagine how easier it will make
>> things for Webkit if they are going to implement ARIA support!
>>    
> And hopefully help IE and Opera do something similar that Firefox does.
> However, I think we really need the equivalent of the CSS acid test for
> ARIA. It's a point of pride to do well in that. It could just test MSAA
> for now, which would let us test Opera, Safari and IE. That might be
> something we need you guys to do, and I think it fits in with your
> grants. What do you think?
>  

It does fit but will have to be prioritized. I think it is very
worthwhile work and I'll try to catch you on IRC soonish (Monday latest)
to discuss.

cheers,
David
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility