---------- Forwarded message ---------- From: Aaron <kahunaco...@gmail.com> Date: Thursday, July 16, 2009 Subject: [free-aria] Keyboard Navigation & ARIA To: Free ARIA Community <free-aria@googlegroups.com>
Here's the aria menu I've been working on. It sounds pretty good in screereaders at this point.
Some background: We are working on an unobtrusive, declarative widget framework, based on jQuery UI. We modify some of UI's widgets, and have developed our own based on their framework. We decided against YUI because it is coming out with a new version soon and jQuery is simpler to work with.
The menu widget we are developing is similar to YUI's menubar, except it uses simple <ul> semantics in contrast to YUI's embedded divs within <ul>s. Here it is (it is not really styled much at this point). Here you go: http://mini.ncbi.nih.gov/4e1
Comments are welcome.
On Jul 16, 2:38 am, "Schnabel, Stefan" <stefan.schna...@sap.com> wrote: > Codetalks.org is always thankful for working online ARIA examples. Just a hint. > Drop us a line to the URL.
> Regards > Stefan
> -----Original Message----- > From: free-aria@googlegroups.com [mailto:free-aria@googlegroups.com] On Behalf Of Aaron > Sent: Mittwoch, 15. Juli 2009 16:29 > To: Free ARIA Community > Subject: [LIKELY JUNK][free-aria] Re: Keyboard Navigation & ARIA
> Great thanks everyone for their input. I got my menubar widget to work > quite well with ARIA, JAWS10 and NVDA.
> On Jul 14, 12:46 pm, Benjamin Hawkes-Lewis > <bhawkesle...@googlemail.com> wrote: > > Sorry. Previous reply - an old draft - sent in error.
> > On 8/7/09 20:40, Aaron Leventhal wrote:
> > > ARIA doesn't try to be HTML. If the role and ARIA attributes started > > > driving behavior instead of acting just as an informer to ATs, then it > > > would break everything that uses ARIA right now. For a given browser > > > it would be unpredictable. The strength of ARIA is that it makes it > > > possible to do your own thing and make it accessible.
> > Regrettably, I think the convention that UAs shouldn't use ARIA works to > > prevent that.
> > ARIA certainly makes it possible to make arbitrary markup accessible to > > users of AT (or automation frameworks) that interact and represent via > > the system accessibility API.
> > But in so far as it restricts user agents to simply exposing ARIA > > information to assistive technology, it risking leaving out users who > > either aren't using AT, aren't using AT that queries the system API, or > > are using complex combinations of AT and user agent UIs.
> > ARIA can certainly help towards partially repairing things when authors > > have made the mistake of treating HTML as HyperText Made Up Language > > (like with the Dojo project that rebuilt checkbox controls with "div" > > elements). Sadly, I think the target market for reinventing controls in > > this way is already moving on to direct draw technologies not covered by > > ARIA, like "canvas".
> > ARIA can also improve the accessibility for some system-API-based AT > > users of interfaces that are already pretty accessible to other user > > groups (I'm thinking especially of live regions here, even though > > they've lost the handy ability to prioritize messages).
> > But I don't this adds up to a licence to "do your own thing".
> > There's a danger of "accessibility" looking like shorthand for "now > > works for blind users of new versions of popular screenreaders" here.
> > Just to take one example - consider Susan. She has early onset > > Parkinson's and struggles to use a mouse but can peck away slowly at a > > keyboard. She accesses an SVG-based interface that has landmark and > > heading roles. Why shouldn't a keyboard-friendly user agent like Opera, > > which already binds keyboard shortcuts to things like headings, links, > > and form controls, bind a keyboard shortcut to the "heading", "main" and > > "search" landmark roles so Susan can skip between headings, to the main > > content, or to site search. How does it make sense for some logical > > headings to be handled by Opera's shortcuts and other logical headings > > by some hypothetical AT add-on? Or again, if there's a drag and drop > > interface, why shouldn't Susan be able to use Opera-provided shortcuts > > to manipulate it?
> > One quickly arrives at the conclusion that if ARIA can't help in these > > use-cases, then the recommendation should be to mix XHTML and SVG inline > > in order to use XHTML's heading elements, and forget about > > role="heading" entirely.
> > Incidentally, it's not very clear to me whether Opera would be clearly > > breaching an actual conformance requirement, as opposed to convention, > > if it exposed such shortcuts or not. "WAI-ARIA processing by the user > > agent MUST NOT interfere with the normal operation of the built-in
----- Original Message ----- From: "Scott González" <scott.gonza...@gmail.com>
To: <jquery-ui-dev@googlegroups.com>
Sent: Thursday, July 16, 2009 8:26 PM
Subject: [jquery-ui-dev] Fwd: [free-aria] Keyboard Navigation & ARIA
Here's a link to a menu implementation with ARIA. I haven't looked at
this yet but it might be useful for some ideas.
---------- Forwarded message ----------
From: Aaron <kahunaco...@gmail.com>
Date: Thursday, July 16, 2009
Subject: [free-aria] Keyboard Navigation & ARIA
To: Free ARIA Community <free-aria@googlegroups.com>
Here's the aria menu I've been working on. It sounds pretty good in
screereaders at this point.
Some background:
We are working on an unobtrusive, declarative widget framework, based
on jQuery UI. We modify some of UI's widgets, and have developed our
own based on their framework. We decided against YUI because it is
coming out with a new version soon and jQuery is simpler to work with.
The menu widget we are developing is similar to YUI's menubar, except
it uses simple <ul> semantics in contrast to YUI's embedded divs
within <ul>s. Here it is (it is not really styled much at this point).
Here you go:
http://mini.ncbi.nih.gov/4e1
Comments are welcome.
On Jul 16, 2:38 am, "Schnabel, Stefan" <stefan.schna...@sap.com>
wrote:
> Codetalks.org is always thankful for working online ARIA examples. Just a > hint.
> Drop us a line to the URL.
> Regards
> Stefan
> -----Original Message-----
> From: free-aria@googlegroups.com [mailto:free-aria@googlegroups.com] On > Behalf Of Aaron
> Sent: Mittwoch, 15. Juli 2009 16:29
> To: Free ARIA Community
> Subject: [LIKELY JUNK][free-aria] Re: Keyboard Navigation & ARIA
> Great thanks everyone for their input. I got my menubar widget to work
> quite well with ARIA, JAWS10 and NVDA.
> On Jul 14, 12:46 pm, Benjamin Hawkes-Lewis
> <bhawkesle...@googlemail.com> wrote:
> > Sorry. Previous reply - an old draft - sent in error.
> > On 8/7/09 20:40, Aaron Leventhal wrote:
> > > ARIA doesn't try to be HTML. If the role and ARIA attributes started
> > > driving behavior instead of acting just as an informer to ATs, then it
> > > would break everything that uses ARIA right now. For a given browser
> > > it would be unpredictable. The strength of ARIA is that it makes it
> > > possible to do your own thing and make it accessible.
> > Regrettably, I think the convention that UAs shouldn't use ARIA works to
> > prevent that.
> > ARIA certainly makes it possible to make arbitrary markup accessible to
> > users of AT (or automation frameworks) that interact and represent via
> > the system accessibility API.
> > But in so far as it restricts user agents to simply exposing ARIA
> > information to assistive technology, it risking leaving out users who
> > either aren't using AT, aren't using AT that queries the system API, or
> > are using complex combinations of AT and user agent UIs.
> > ARIA can certainly help towards partially repairing things when authors
> > have made the mistake of treating HTML as HyperText Made Up Language
> > (like with the Dojo project that rebuilt checkbox controls with "div"
> > elements). Sadly, I think the target market for reinventing controls in
> > this way is already moving on to direct draw technologies not covered by
> > ARIA, like "canvas".
> > ARIA can also improve the accessibility for some system-API-based AT
> > users of interfaces that are already pretty accessible to other user
> > groups (I'm thinking especially of live regions here, even though
> > they've lost the handy ability to prioritize messages).
> > But I don't this adds up to a licence to "do your own thing".
> > There's a danger of "accessibility" looking like shorthand for "now
> > works for blind users of new versions of popular screenreaders" here.
> > Just to take one example - consider Susan. She has early onset
> > Parkinson's and struggles to use a mouse but can peck away slowly at a
> > keyboard. She accesses an SVG-based interface that has landmark and
> > heading roles. Why shouldn't a keyboard-friendly user agent like Opera,
> > which already binds keyboard shortcuts to things like headings, links,
> > and form controls, bind a keyboard shortcut to the "heading", "main" and
> > "search" landmark roles so Susan can skip between headings, to the main
> > content, or to site search. How does it make sense for some logical
> > headings to be handled by Opera's shortcuts and other logical headings
> > by some hypothetical AT add-on? Or again, if there's a drag and drop
> > interface, why shouldn't Susan be able to use Opera-provided shortcuts
> > to manipulate it?
> > One quickly arrives at the conclusion that if ARIA can't help in these
> > use-cases, then the recommendation should be to mix XHTML and SVG inline
> > in order to use XHTML's heading elements, and forget about
> > role="heading" entirely.
> > Incidentally, it's not very clear to me whether Opera would be clearly
> > breaching an actual conformance requirement, as opposed to convention,
> > if it exposed such shortcuts or not. "WAI-ARIA processing by the user
> > agent MUST NOT interfere with the normal operation of the built-in
> ----- Original Message -----
> From: "Scott González" <scott.gonza...@gmail.com>
> To: <jquery-ui-dev@googlegroups.com>
> Sent: Thursday, July 16, 2009 8:26 PM
> Subject: [jquery-ui-dev] Fwd: [free-aria] Keyboard Navigation & ARIA
> Here's a link to a menu implementation with ARIA. I haven't looked at
> this yet but it might be useful for some ideas.
> ---------- Forwarded message ----------
> From: Aaron <kahunaco...@gmail.com>
> Date: Thursday, July 16, 2009
> Subject: [free-aria] Keyboard Navigation & ARIA
> To: Free ARIA Community <free-aria@googlegroups.com>
> Here's the aria menu I've been working on. It sounds pretty good in
> screereaders at this point.
> Some background:
> We are working on an unobtrusive, declarative widget framework, based
> on jQuery UI. We modify some of UI's widgets, and have developed our
> own based on their framework. We decided against YUI because it is
> coming out with a new version soon and jQuery is simpler to work with.
> The menu widget we are developing is similar to YUI's menubar, except
> it uses simple <ul> semantics in contrast to YUI's embedded divs
> within <ul>s. Here it is (it is not really styled much at this point).
> Here you go:
> http://mini.ncbi.nih.gov/4e1
> Comments are welcome.
> On Jul 16, 2:38 am, "Schnabel, Stefan" <stefan.schna...@sap.com>
> wrote:
> > Codetalks.org is always thankful for working online ARIA examples. Just a
> > hint.
> > Drop us a line to the URL.
> > Regards
> > Stefan
> > -----Original Message-----
> > From: free-aria@googlegroups.com [mailto:free-aria@googlegroups.com] On
> > Behalf Of Aaron
> > Sent: Mittwoch, 15. Juli 2009 16:29
> > To: Free ARIA Community
> > Subject: [LIKELY JUNK][free-aria] Re: Keyboard Navigation & ARIA
> > Great thanks everyone for their input. I got my menubar widget to work
> > quite well with ARIA, JAWS10 and NVDA.
> > On Jul 14, 12:46 pm, Benjamin Hawkes-Lewis
> > <bhawkesle...@googlemail.com> wrote:
> > > Sorry. Previous reply - an old draft - sent in error.
> > > On 8/7/09 20:40, Aaron Leventhal wrote:
> > > > ARIA doesn't try to be HTML. If the role and ARIA attributes started
> > > > driving behavior instead of acting just as an informer to ATs, then
> it
> > > > would break everything that uses ARIA right now. For a given browser
> > > > it would be unpredictable. The strength of ARIA is that it makes it
> > > > possible to do your own thing and make it accessible.
> > > Regrettably, I think the convention that UAs shouldn't use ARIA works
> to
> > > prevent that.
> > > ARIA certainly makes it possible to make arbitrary markup accessible to
> > > users of AT (or automation frameworks) that interact and represent via
> > > the system accessibility API.
> > > But in so far as it restricts user agents to simply exposing ARIA
> > > information to assistive technology, it risking leaving out users who
> > > either aren't using AT, aren't using AT that queries the system API, or
> > > are using complex combinations of AT and user agent UIs.
> > > ARIA can certainly help towards partially repairing things when authors
> > > have made the mistake of treating HTML as HyperText Made Up Language
> > > (like with the Dojo project that rebuilt checkbox controls with "div"
> > > elements). Sadly, I think the target market for reinventing controls in
> > > this way is already moving on to direct draw technologies not covered
> by
> > > ARIA, like "canvas".
> > > ARIA can also improve the accessibility for some system-API-based AT
> > > users of interfaces that are already pretty accessible to other user
> > > groups (I'm thinking especially of live regions here, even though
> > > they've lost the handy ability to prioritize messages).
> > > But I don't this adds up to a licence to "do your own thing".
> > > There's a danger of "accessibility" looking like shorthand for "now
> > > works for blind users of new versions of popular screenreaders" here.
> > > Just to take one example - consider Susan. She has early onset
> > > Parkinson's and struggles to use a mouse but can peck away slowly at a
> > > keyboard. She accesses an SVG-based interface that has landmark and
> > > heading roles. Why shouldn't a keyboard-friendly user agent like Opera,
> > > which already binds keyboard shortcuts to things like headings, links,
> > > and form controls, bind a keyboard shortcut to the "heading", "main"
> and
> > > "search" landmark roles so Susan can skip between headings, to the main
> > > content, or to site search. How does it make sense for some logical
> > > headings to be handled by Opera's shortcuts and other logical headings
> > > by some hypothetical AT add-on? Or again, if there's a drag and drop
> > > interface, why shouldn't Susan be able to use Opera-provided shortcuts
> > > to manipulate it?
> > > One quickly arrives at the conclusion that if ARIA can't help in these
> > > use-cases, then the recommendation should be to mix XHTML and SVG
> inline
> > > in order to use XHTML's heading elements, and forget about
> > > role="heading" entirely.
> > > Incidentally, it's not very clear to me whether Opera would be clearly
> > > breaching an actual conformance requirement, as opposed to convention,
> > > if it exposed such shortcuts or not. "WAI-ARIA processing by the user
> > > agent MUST NOT interfere with the normal operation of the built-in
> ----- Original Message -----
> From: "Scott González" <scott.gonza...@gmail.com>
> To: <jquery-ui-dev@googlegroups.com>
> Sent: Thursday, July 16, 2009 8:26 PM
> Subject: [jquery-ui-dev] Fwd: [free-aria] Keyboard Navigation & ARIA
> Here's a link to a menu implementation with ARIA. I haven't looked at
> this yet but it might be useful for some ideas.
> ---------- Forwarded message ----------
> From: Aaron <kahunaco...@gmail.com>
> Date: Thursday, July 16, 2009
> Subject: [free-aria] Keyboard Navigation & ARIA
> To: Free ARIA Community <free-aria@googlegroups.com>
> Here's the aria menu I've been working on. It sounds pretty good in
> screereaders at this point.
> Some background:
> We are working on an unobtrusive, declarative widget framework, based
> on jQuery UI. We modify some of UI's widgets, and have developed our
> own based on their framework. We decided against YUI because it is
> coming out with a new version soon and jQuery is simpler to work with.
> The menu widget we are developing is similar to YUI's menubar, except
> it uses simple <ul> semantics in contrast to YUI's embedded divs
> within <ul>s. Here it is (it is not really styled much at this point).
> Here you go:
> http://mini.ncbi.nih.gov/4e1
> Comments are welcome.
> On Jul 16, 2:38 am, "Schnabel, Stefan" <stefan.schna...@sap.com>
> wrote:
> > Codetalks.org is always thankful for working online ARIA examples. Just a
> > hint.
> > Drop us a line to the URL.
> > Regards
> > Stefan
> > -----Original Message-----
> > From: free-aria@googlegroups.com [mailto:free-aria@googlegroups.com] On
> > Behalf Of Aaron
> > Sent: Mittwoch, 15. Juli 2009 16:29
> > To: Free ARIA Community
> > Subject: [LIKELY JUNK][free-aria] Re: Keyboard Navigation & ARIA
> > Great thanks everyone for their input. I got my menubar widget to work
> > quite well with ARIA, JAWS10 and NVDA.
> > On Jul 14, 12:46 pm, Benjamin Hawkes-Lewis
> > <bhawkesle...@googlemail.com> wrote:
> > > Sorry. Previous reply - an old draft - sent in error.
> > > On 8/7/09 20:40, Aaron Leventhal wrote:
> > > > ARIA doesn't try to be HTML. If the role and ARIA attributes started
> > > > driving behavior instead of acting just as an informer to ATs, then
> it
> > > > would break everything that uses ARIA right now. For a given browser
> > > > it would be unpredictable. The strength of ARIA is that it makes it
> > > > possible to do your own thing and make it accessible.
> > > Regrettably, I think the convention that UAs shouldn't use ARIA works
> to
> > > prevent that.
> > > ARIA certainly makes it possible to make arbitrary markup accessible to
> > > users of AT (or automation frameworks) that interact and represent via
> > > the system accessibility API.
> > > But in so far as it restricts user agents to simply exposing ARIA
> > > information to assistive technology, it risking leaving out users who
> > > either aren't using AT, aren't using AT that queries the system API, or
> > > are using complex combinations of AT and user agent UIs.
> > > ARIA can certainly help towards partially repairing things when authors
> > > have made the mistake of treating HTML as HyperText Made Up Language
> > > (like with the Dojo project that rebuilt checkbox controls with "div"
> > > elements). Sadly, I think the target market for reinventing controls in
> > > this way is already moving on to direct draw technologies not covered
> by
> > > ARIA, like "canvas".
> > > ARIA can also improve the accessibility for some system-API-based AT
> > > users of interfaces that are already pretty accessible to other user
> > > groups (I'm thinking especially of live regions here, even though
> > > they've lost the handy ability to prioritize messages).
> > > But I don't this adds up to a licence to "do your own thing".
> > > There's a danger of "accessibility" looking like shorthand for "now
> > > works for blind users of new versions of popular screenreaders" here.
> > > Just to take one example - consider Susan. She has early onset
> > > Parkinson's and struggles to use a mouse but can peck away slowly at a
> > > keyboard. She accesses an SVG-based interface that has landmark and
> > > heading roles. Why shouldn't a keyboard-friendly user agent like Opera,
> > > which already binds keyboard shortcuts to things like headings, links,
> > > and form controls, bind a keyboard shortcut to the "heading", "main"
> and
> > > "search" landmark roles so Susan can skip between headings, to the main
> > > content, or to site search. How does it make sense for some logical
> > > headings to be handled by Opera's shortcuts and other logical headings
> > > by some hypothetical AT add-on? Or again, if there's a drag and drop
> > > interface, why shouldn't Susan be able to use Opera-provided shortcuts
> > > to manipulate it?
> > > One quickly arrives at the conclusion that if ARIA can't help in these
> > > use-cases, then the recommendation should be to mix XHTML and SVG
> inline
> > > in order to use XHTML's heading elements, and forget about
> > > role="heading" entirely.
> > > Incidentally, it's not very clear to me whether Opera would be clearly
> > > breaching an actual conformance requirement, as opposed to convention,
> > > if it exposed such shortcuts or not. "WAI-ARIA processing by the user
> > > agent MUST NOT interfere with the normal operation of the built-in
Just a disclaimer...
Still quite a work in progress. I have a few bugs relating to
highlighting menu items, and the code is quite messy. I hope to have a
production ready version in the next few weeks. I will update the
actual content of the page to explain the widget some more.
On Jul 18, 12:18 pm, Scott González <scott.gonza...@gmail.com> wrote:
> > Here's the aria menu I've been working on. It sounds pretty good in
> > screereaders at this point.
> > Some background:
> > We are working on an unobtrusive, declarative widget framework, based
> > on jQuery UI. We modify some of UI's widgets, and have developed our
> > own based on their framework. We decided against YUI because it is
> > coming out with a new version soon and jQuery is simpler to work with.
> > The menu widget we are developing is similar to YUI's menubar, except
> > it uses simple <ul> semantics in contrast to YUI's embedded divs
> > within <ul>s. Here it is (it is not really styled much at this point).
> > Here you go:
> >http://mini.ncbi.nih.gov/4e1
> > Comments are welcome.
> > On Jul 16, 2:38 am, "Schnabel, Stefan" <stefan.schna...@sap.com>
> > wrote:
> > > Codetalks.org is always thankful for working online ARIA examples. Just a
> > > hint.
> > > Drop us a line to the URL.
> > > Regards
> > > Stefan
> > > -----Original Message-----
> > > From: free-aria@googlegroups.com [mailto:free-aria@googlegroups.com] On
> > > Behalf Of Aaron
> > > Sent: Mittwoch, 15. Juli 2009 16:29
> > > To: Free ARIA Community
> > > Subject: [LIKELY JUNK][free-aria] Re: Keyboard Navigation & ARIA
> > > Great thanks everyone for their input. I got my menubar widget to work
> > > quite well with ARIA, JAWS10 and NVDA.
> > > On Jul 14, 12:46 pm, Benjamin Hawkes-Lewis
> > > <bhawkesle...@googlemail.com> wrote:
> > > > Sorry. Previous reply - an old draft - sent in error.
> > > > On 8/7/09 20:40, Aaron Leventhal wrote:
> > > > > ARIA doesn't try to be HTML. If the role and ARIA attributes started
> > > > > driving behavior instead of acting just as an informer to ATs, then
> > it
> > > > > would break everything that uses ARIA right now. For a given browser
> > > > > it would be unpredictable. The strength of ARIA is that it makes it
> > > > > possible to do your own thing and make it accessible.
> > > > Regrettably, I think the convention that UAs shouldn't use ARIA works
> > to
> > > > prevent that.
> > > > ARIA certainly makes it possible to make arbitrary markup accessible to
> > > > users of AT (or automation frameworks) that interact and represent via
> > > > the system accessibility API.
> > > > But in so far as it restricts user agents to simply exposing ARIA
> > > > information to assistive technology, it risking leaving out users who
> > > > either aren't using AT, aren't using AT that queries the system API, or
> > > > are using complex combinations of AT and user agent UIs.
> > > > ARIA can certainly help towards partially repairing things when authors
> > > > have made the mistake of treating HTML as HyperText Made Up Language
> > > > (like with the Dojo project that rebuilt checkbox controls with "div"
> > > > elements). Sadly, I think the target market for reinventing controls in
> > > > this way is already moving on to direct draw technologies not covered
> > by
> > > > ARIA, like "canvas".
> > > > ARIA can also improve the accessibility for some system-API-based AT
> > > > users of interfaces that are already pretty accessible to other user
> > > > groups (I'm thinking especially of live regions here, even though
> > > > they've lost the handy ability to prioritize messages).
> > > > But I don't this adds up to a licence to "do your own thing".
> > > > There's a danger of "accessibility" looking like shorthand for "now
> > > > works for blind users of new versions of popular screenreaders" here.
> > > > Just to take one example - consider Susan. She has early onset
> > > > Parkinson's and struggles to use a mouse but can peck away slowly at a
> > > > keyboard. She accesses an SVG-based interface that has landmark and
> > > > heading roles. Why shouldn't a keyboard-friendly user agent like Opera,
> > > > which already binds keyboard shortcuts to things like headings, links,
> > > > and form controls, bind a keyboard shortcut to the "heading", "main"
> > and
> > > > "search" landmark roles so Susan can skip between headings, to the main
> > > > content, or to site search. How does it make sense for some logical
> > > > headings to be handled by Opera's shortcuts and other logical headings
> > > > by some hypothetical AT add-on? Or again, if there's a drag and drop
> > > > interface, why shouldn't Susan be able to use Opera-provided shortcuts
> > > > to manipulate it?
> > > > One quickly arrives at the conclusion that if ARIA can't help in these
> > > > use-cases, then the recommendation should be to mix XHTML and SVG
> > inline
> > > > in order to use XHTML's heading elements, and forget about
> > > > role="heading" entirely.
> > > > Incidentally, it's not very clear to me whether Opera would be clearly
> > > > breaching an actual conformance requirement, as opposed to convention,
> > > > if it exposed such shortcuts or not. "WAI-ARIA processing by the user
> > > > agent MUST NOT interfere with the normal operation of the built-in
