E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 34 (In chronological order)

From: Jordan Wilson
Date: Tue, Sep 02 2014 12:24PM
Subject: Keyboard navigation using arrows only
No previous message | Next message →

A question about keyboard navigation using arrow-only navigation instead of tabbing. Is that at all acceptable? A client site has good keyboard navigation if you use the arrow keys alone and they inform users that their site is optimized to be used that way. Unfortunately the site doesn't work at all with standard tabbing through content.

I'm assuming that isn't acceptable, but since the arrow key navigation is actually quite good it seems intentional. They clearly spent a lot of time and effort ensuring the arrow navigation, so I figured I'd ask the community.

From: Mallory van Achterberg
Date: Tue, Sep 02 2014 1:27PM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

As a keyboard user, I expect to tab most of the time, and attempt
arrow keys when tab seems to skip stuff. Meaning, even though it
seems regularly recommended by accessibility experts "because it's
how Desktop apps work", the web has built up its own conventions
and non-screenreader-users are, except for old Opera users like me,
used to tabbing most of the time.

That said, I made a mega-menu where tab stuck to the main-level
links, and arrows were needed to go into the submenus. Again, relying
on that "tab isn't going in there so lemme try arrows" idea. So
always a bit of mystery-meat there for users.

If it's a specialised weirdo widget, adding a sentence with how-to
wouldn't be a bad thing.
_mallory

On Tue, Sep 02, 2014 at 06:24:18PM +0000, Jordan Wilson wrote:
> A question about keyboard navigation using arrow-only navigation instead of tabbing. Is that at all acceptable? A client site has good keyboard navigation if you use the arrow keys alone and they inform users that their site is optimized to be used that way. Unfortunately the site doesn't work at all with standard tabbing through content.
>
> I'm assuming that isn't acceptable, but since the arrow key navigation is actually quite good it seems intentional. They clearly spent a lot of time and effort ensuring the arrow navigation, so I figured I'd ask the community.
> > >

From: Mallory van Achterberg
Date: Tue, Sep 02 2014 1:31PM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

On Tue, Sep 02, 2014 at 06:24:18PM +0000, Jordan Wilson wrote:
> They clearly spent a lot of time and effort ensuring the arrow navigation, so I figured I'd ask the community.

I gotta wonder... why?? It's like carefully making buttons out of
spans with all the manual roles and scripting.

Have you asked them what problem they were solving?
_mallory

From: Jared Smith
Date: Tue, Sep 02 2014 1:09PM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

Why did they not implement standard keyboard navigation? Except for
some highly interactive widgets or web applications, I can see no
reason why standard Tab navigation would not be both possible and
optimal.

Another important consideration is that arrow key navigation is not
going to work when a screen reader is used. The arrow keys are
intercepted by the screen reader to control other reading
functionality (line by line, for example). You can get around this by
triggering forms/application mode, but this essentially disables all
other screen reader keyboard commands, such as navigation by headings,
etc.

Jared

From: Jordan Wilson
Date: Tue, Sep 02 2014 1:22PM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

I haven't gotten to the point of getting access to their internal
development team about the why and how. Its not even just a widget, its
the whole site. It seemed so intentional I was afraid I had missed
something.

The arrow keys getting intercepted in screen readers is a great point I
hadn't thought of yet.

Hopefully I get a chance to talk to them in the near future, thanks for
your perspectives!



On 9/2/14 3:31 PM, "Mallory van Achterberg" < = EMAIL ADDRESS REMOVED = >
wrote:

>On Tue, Sep 02, 2014 at 06:24:18PM +0000, Jordan Wilson wrote:
>> They clearly spent a lot of time and effort ensuring the arrow
>>navigation, so I figured I'd ask the community.
>
>I gotta wonder... why?? It's like carefully making buttons out of
>spans with all the manual roles and scripting.
>
>Have you asked them what problem they were solving?
>_mallory
>>>

From: Michael Tangen
Date: Tue, Sep 02 2014 1:40PM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

Jordan, I've been working on this whole keyboard navigation thing and been
doing some extensive research on various approaches to this. I managed to
get a working prototype that at least works with JAWS and using both tab
and arrow keys — http://designbymichael.com/test/menu/

It all has to do with the placement of role="menu", role="menuitem" and a
variety of other ARIA attributes. A few basics that I learned:


- Generally speaking sub-menus (<UL> tags) get a role="menu" attribute
- All menu items (<A> tags) get a role="menuitem" attribute
- Menu items with a submenu also get the attribute aria-haspopup="true"
- Use the attribute aria-hidden="VALUE" (true/false) on submenus to
tell the browser and assistive technology if an item is hidden or not
- Also use CSS attributes (display and visibility) to control subnav
visibility
- I also found that for some reason, the *first level* LI tags need an
attribute role="menu" if you want the presence of a sub-menu to be
announced. But generally speaking, all submenu UL tags should have a
role="menu" attribute.

Hope that helps a little.




On Tue, Sep 2, 2014 at 2:22 PM, Jordan Wilson < = EMAIL ADDRESS REMOVED = >
wrote:

> I haven't gotten to the point of getting access to their internal
> development team about the why and how. Its not even just a widget, its
> the whole site. It seemed so intentional I was afraid I had missed
> something.
>
> The arrow keys getting intercepted in screen readers is a great point I
> hadn't thought of yet.
>
> Hopefully I get a chance to talk to them in the near future, thanks for
> your perspectives!
>
>
>
> On 9/2/14 3:31 PM, "Mallory van Achterberg" < = EMAIL ADDRESS REMOVED = >
> wrote:
>
> >On Tue, Sep 02, 2014 at 06:24:18PM +0000, Jordan Wilson wrote:
> >> They clearly spent a lot of time and effort ensuring the arrow
> >>navigation, so I figured I'd ask the community.
> >
> >I gotta wonder... why?? It's like carefully making buttons out of
> >spans with all the manual roles and scripting.
> >
> >Have you asked them what problem they were solving?
> >_mallory
> >> >> >>
> > > >

From: Ryan E. Benson
Date: Tue, Sep 02 2014 2:01PM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

How do they notify people? People just want to go in and use the site. This
forces me to use caret mode in my browser as a keyboard user, which is
painful at times. The user will still have to use the tab key to navigate
form fields. If their script doesn't allow that, they have larger issues.

--
Ryan E. Benson


On Tue, Sep 2, 2014 at 2:24 PM, Jordan Wilson < = EMAIL ADDRESS REMOVED = >
wrote:

> A question about keyboard navigation using arrow-only navigation instead
> of tabbing. Is that at all acceptable? A client site has good keyboard
> navigation if you use the arrow keys alone and they inform users that their
> site is optimized to be used that way. Unfortunately the site doesn't work
> at all with standard tabbing through content.
>
> I'm assuming that isn't acceptable, but since the arrow key navigation is
> actually quite good it seems intentional. They clearly spent a lot of time
> and effort ensuring the arrow navigation, so I figured I'd ask the
> community.
> > > >

From: Mallory van Achterberg
Date: Tue, Sep 02 2014 2:50PM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

On Tue, Sep 02, 2014 at 02:40:22PM -0500, Michael Tangen wrote:
> It all has to do with the placement of role="menu", role="menuitem" and a
> variety of other ARIA attributes.

My fault for mentioning menus... it's apparently the entire site
in this case.

> - I also found that for some reason, the *first level* LI tags need an
> attribute role="menu" if you want the presence of a sub-menu to be
> announced.
Yeah the specs mention the main ul is "menubar" while the li's are
"menu"s.
I would think this is to do with the type of "menu" the specs seem
to be written for: application menus where each option is often
itself a sort of mini-application-menu.

_mallory

From: Michael Tangen
Date: Tue, Sep 02 2014 5:40PM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

When a link tag has the aria attribute aria-haspopup="true", JAWS actually
announces the words "has submenu". So really, the arrow is only of value
to sighted users.


On Tue, Sep 2, 2014 at 3:50 PM, Mallory van Achterberg <
= EMAIL ADDRESS REMOVED = > wrote:

> On Tue, Sep 02, 2014 at 02:40:22PM -0500, Michael Tangen wrote:
> > It all has to do with the placement of role="menu", role="menuitem" and a
> > variety of other ARIA attributes.
>
> My fault for mentioning menus... it's apparently the entire site
> in this case.
>
> > - I also found that for some reason, the *first level* LI tags need an
> > attribute role="menu" if you want the presence of a sub-menu to be
> > announced.
> Yeah the specs mention the main ul is "menubar" while the li's are
> "menu"s.
> I would think this is to do with the type of "menu" the specs seem
> to be written for: application menus where each option is often
> itself a sort of mini-application-menu.
>
> _mallory
> > > >

From: Bryan Garaventa
Date: Tue, Sep 02 2014 5:52PM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

>When a link tag has the aria attribute aria-haspopup="true", JAWS actually announces the words "has submenu". So really, the arrow
is only of value to sighted users.

That's not true actually.

Regarding ARIA Menus, the Windows platform UI equivalent for this is documented at
http://msdn.microsoft.com/en-us/library/system.windows.controls.contextmenu.aspx

When an ARIA Menu is constructed strictly according to spec, It causes specific events to fire in the browser, which Assistive
Technologies then use to ensure accessibility by customizing feedback and behavior.

This process is documented in the UAIG, at
http://www.w3.org/TR/wai-aria-implementation/#mapping_events_menus

If you try the following demo using JAWS in IE or FF, you will see this in action:
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Menus/Vertical%20(Internal%20Content)/demo.htm

From: Michael Tangen
Date: Wed, Sep 03 2014 10:11AM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

I'm not talking about Windows menus, Bryan — just basic web-based
navigation. With a deep-linking menu on a website, both the attributes
aria-haspopup on the <a> tag and the role="menu" on the submenu UL tag cue
JAWS in on that there's a submenu and announce it accordingly. The
physical presence of an "arrow" in a website menu does not necessarily add
significant value (in my opinion) when the aforementioned attributes
facilitate the announcing of the presence of a submenu. Can it add some
level of benefit? Sure, but I think most of the value is for sited users.
Just my take on it.

Also for what it's worth, Microsoft Windows controls are irrelevant when
you're trying to build websites and be agnostic about operating systems and
browsers.




On Tue, Sep 2, 2014 at 6:52 PM, Bryan Garaventa <
= EMAIL ADDRESS REMOVED = > wrote:

> >When a link tag has the aria attribute aria-haspopup="true", JAWS
> actually announces the words "has submenu". So really, the arrow
> is only of value to sighted users.
>
> That's not true actually.
>
> Regarding ARIA Menus, the Windows platform UI equivalent for this is
> documented at
>
> http://msdn.microsoft.com/en-us/library/system.windows.controls.contextmenu.aspx
>
> When an ARIA Menu is constructed strictly according to spec, It causes
> specific events to fire in the browser, which Assistive
> Technologies then use to ensure accessibility by customizing feedback and
> behavior.
>
> This process is documented in the UAIG, at
> http://www.w3.org/TR/wai-aria-implementation/#mapping_events_menus
>
> If you try the following demo using JAWS in IE or FF, you will see this in
> action:
>
> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Menus/Vertical%20(Internal%20Content)/demo.htm
>
>
>

From: Jonathan Avila
Date: Wed, Sep 03 2014 10:23AM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

> Also for what it's worth, Microsoft Windows controls are irrelevant when you're trying to build websites and be agnostic about operating systems and browsers.

ARIA controls are converted into platform level accessibility APIs by the browser so they may be consumed by user agents such as screen readers. In fact many ARIA controls and composite structures are based on equivalent OS level accessibility APIs. So, there is a close relationship between these two concepts for consistency among assistive technology with native and web apps.

Jonathan

From: Bryan Garaventa
Date: Wed, Sep 03 2014 10:25AM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

I understand, my point isn't with your implementation, but with the use of ARIA for this purpose, which won't work as expected for screen reader users.

The reason for ARIA menu markup isn't just to announce 'submenu' or 'menu', but this actually causes specific behaviors to occur within browser/AT combinations, and using ARIA just to get screen readers to announce a specific keyword is an ARIA hack that goes against the spec. Meaning that it won't work reliably across devices as a result.

You would be better served using offscreen text as part of the link in order to achieve this, than you would using ARIA improperly for this purpose.

I don't mean to sound harsh about this, but I see implementations such as these every day, and they never work reliably across browsers and devices when programmed in ways that are not expected by user agents and ATs in accord with the spec.

From: Bryan Garaventa
Date: Wed, Sep 03 2014 10:27AM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

+1 Looks like we were writing at the same time; exactly.

From: Michael Tangen
Date: Wed, Sep 03 2014 10:29AM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

I get your point, but the problem is that all of the documentation out
there for creating accessible web menus is in itself both convoluted and
inaccessible to the average web developer/designer. You know why there's a
lot of "hacks" out there? This would be the reason.


On Wed, Sep 3, 2014 at 11:25 AM, Bryan Garaventa <
= EMAIL ADDRESS REMOVED = > wrote:

> I understand, my point isn't with your implementation, but with the use of
> ARIA for this purpose, which won't work as expected for screen reader users.
>
> The reason for ARIA menu markup isn't just to announce 'submenu' or
> 'menu', but this actually causes specific behaviors to occur within
> browser/AT combinations, and using ARIA just to get screen readers to
> announce a specific keyword is an ARIA hack that goes against the spec.
> Meaning that it won't work reliably across devices as a result.
>
> You would be better served using offscreen text as part of the link in
> order to achieve this, than you would using ARIA improperly for this
> purpose.
>
> I don't mean to sound harsh about this, but I see implementations such as
> these every day, and they never work reliably across browsers and devices
> when programmed in ways that are not expected by user agents and ATs in
> accord with the spec.
>
>

From: Mallory van Achterberg
Date: Wed, Sep 03 2014 2:16PM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

On Wed, Sep 03, 2014 at 11:29:52AM -0500, Michael Tangen wrote:
> I get your point, but the problem is that all of the documentation out
> there for creating accessible web menus is in itself both convoluted and
> inaccessible to the average web developer/designer. You know why there's a
> lot of "hacks" out there? This would be the reason.

I have to agree with this, and I feel I'm not too horrible at reading
"spec-ese". Tutorials and blogs with proven, correct implementations
are the only thing saving a lot of us at the moment, which is a bit
of a shame because with for example these menus (if one chooses the
convoluted-in-my-opinion menu roles instead of the traditional
unordered nested list) is that if you use the wrong roles, you can
easily totally break the whole menu.

And even when you get it right, a "typical" (non-developer) screen
reader user may still have no idea wtf this menu (or whatever widget)
is or how to use it (as evidenced by my co-tester on a website which
used a correct implementation of the menu-role setup for a mega-menu,
where she was quite confused as what the structure actually meant,
especially as NVDA (her normal reader) and JAWS15 (her testing reader)
both worked but acted slightly different).
...and yes, users have a responsibility to learn their software but
being both relatively "new" and often not so straight-forward means
there are a good number of users having trouble figuring out correct
implementations and hearing new things being announced.

_mallory

From: Michael Tangen
Date: Wed, Sep 03 2014 3:04PM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

+1 Mallory

A lot of us web developers are *trying hard* to be compliant, but let's be
honest — those documenting ARIA standards for web developers are not doing
us any favors, those of us who don't work with system properties and
operating system level environments. Most web developers work with HTML
and Javascript, or perhaps CSS — we're largely familiar with those sorts of
things.

I realize this is a sidebar to the actual context of this thread, but those
responsible for ARIA documentation really need to address how they
communicate standards to those that don't work on the operating system
level (or understand it's deep level of complexity), but rather work on
things like DOM structure of HTML, Javascript events, and CSS properties.
If those documenting ARIA standards could translate those standards for
web professionals in terminology and contexts we understand and work with,
then I think we'd be a lot further along in building menus that were much
more accessible.


On Wed, Sep 3, 2014 at 3:16 PM, Mallory van Achterberg <
= EMAIL ADDRESS REMOVED = > wrote:

> On Wed, Sep 03, 2014 at 11:29:52AM -0500, Michael Tangen wrote:
> > I get your point, but the problem is that all of the documentation out
> > there for creating accessible web menus is in itself both convoluted and
> > inaccessible to the average web developer/designer. You know why
> there's a
> > lot of "hacks" out there? This would be the reason.
>
> I have to agree with this, and I feel I'm not too horrible at reading
> "spec-ese". Tutorials and blogs with proven, correct implementations
> are the only thing saving a lot of us at the moment, which is a bit
> of a shame because with for example these menus (if one chooses the
> convoluted-in-my-opinion menu roles instead of the traditional
> unordered nested list) is that if you use the wrong roles, you can
> easily totally break the whole menu.
>
> And even when you get it right, a "typical" (non-developer) screen
> reader user may still have no idea wtf this menu (or whatever widget)
> is or how to use it (as evidenced by my co-tester on a website which
> used a correct implementation of the menu-role setup for a mega-menu,
> where she was quite confused as what the structure actually meant,
> especially as NVDA (her normal reader) and JAWS15 (her testing reader)
> both worked but acted slightly different).
> ...and yes, users have a responsibility to learn their software but
> being both relatively "new" and often not so straight-forward means
> there are a good number of users having trouble figuring out correct
> implementations and hearing new things being announced.
>
> _mallory
> > > >

From: Bryan Garaventa
Date: Wed, Sep 03 2014 5:07PM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

I understand your points, and those documenting the standards are aware of and do understand this problem as well, which isn't helped by the proliferation of outdated, half-correct, and incorrect data distributed across the web regarding ARIA that is publically accessible for all developers.

If I may ask, did reading the training guide at
http://whatsock.com/training/
help at all? A little bit?

This was written to educate standard developers with a background in HTML and JavaScript with little to no knowledge of ARIA, for the purpose of breaking down these concepts into sensible primary topics in order to make learning how ARIA works, and how it can be used properly, easier for those developers unfamiliar with ARIA that make up the majority worldwide.

In order to ensure the highest level of accuracy possible, and so as not to add to the prolific amount of bad ARIA advice globally, this was a collaborative effort with W3C PFWG members in order to ensure that this would be true before it was released publically.

Since I'm still in the process of fine-tuning the details, please let me know where anything is unclear and I'll be happy to clarify and expound the sections where this occurs.

Best wishes,
Bryan

From: Michael Tangen
Date: Wed, Sep 03 2014 10:35PM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

I did read through that document, along with a variety of others like
Terril Thompson's blog and WebAIM. It was modestly helpful, but when it
came to gleaning information from it to the specific context of a
deeply-nested UL-based menu (one typical of a government entity), it wasn't
nearly as helpful. The horizontal and vertical examples were not
applicable — we don't typically see a single button clicked to engage a
large menu, but rather an opening UL list of several items, each with their
own deep list of descendants, up to five or six levels deep. Mega-menus,
generally-speaking, do not work well for government agencies or
organizations with vast amounts of information that cannot be organized
into two or three levels of navigation.

What web developers are looking for is pretty simple (and I know this from
my discussions with colleagues and reading other developer blogs frustrated
by the lack of cohesive and concise information on the subject). They want
to know what the required mark-up is for their nested UL lists — what goes
in the first <navigation> and <ul> tags, what goes in those first level of
<li> and <a> tags, and what goes in the descendant <ul> <li> and <a> tags.
They also want to know what are the proper CSS attributes to use in their
stylesheet when hiding and displaying the children of a menu item.
Everything else (within that context of developing accessible navigation)
is just noise.

One other thing about the examples (your horizontal and vertical menus),
there is a lot of ARIA-related controls and attributes that aren't
necessary when a menu is contained within the DOM's structure like
aria-owns, aria-posinset, aria-setsize. The example uses hidden divs out
of the context of the navigation (hence the extra controls and attributes,
I know). But most navigation these days, as someone pointed out earlier is
either deep UL trees or the so-called "mega-menu."

If those that develop some of the ARIA documentation for web developers
would like another pair of eyes to read for "developer accessibility" (in
terms of understanding the documentation....which I do believe is yet
another aspect of WCAG 2.0 guidelines), I'd be happy to try and help if
I've got some time.





On Wed, Sep 3, 2014 at 6:07 PM, Bryan Garaventa <
= EMAIL ADDRESS REMOVED = > wrote:

> I understand your points, and those documenting the standards are aware of
> and do understand this problem as well, which isn't helped by the
> proliferation of outdated, half-correct, and incorrect data distributed
> across the web regarding ARIA that is publically accessible for all
> developers.
>
> If I may ask, did reading the training guide at
> http://whatsock.com/training/
> help at all? A little bit?
>
> This was written to educate standard developers with a background in HTML
> and JavaScript with little to no knowledge of ARIA, for the purpose of
> breaking down these concepts into sensible primary topics in order to make
> learning how ARIA works, and how it can be used properly, easier for those
> developers unfamiliar with ARIA that make up the majority worldwide.
>
> In order to ensure the highest level of accuracy possible, and so as not
> to add to the prolific amount of bad ARIA advice globally, this was a
> collaborative effort with W3C PFWG members in order to ensure that this
> would be true before it was released publically.
>
> Since I'm still in the process of fine-tuning the details, please let me
> know where anything is unclear and I'll be happy to clarify and expound the
> sections where this occurs.
>
> Best wishes,
> Bryan
>
>

From: Bryan Garaventa
Date: Thu, Sep 04 2014 12:43AM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

Thanks, I appreciate the feedback.

The point of the demos isn't to be overly complicated or to represent mega-menus, but to convey what ATs like screen readers convey when encountering properly coded ARIA Menu constructs. It's true that aria-owns isn't strictly necessary, but it does explicitly set a parent child relationship that, when more fully supported by browsers, may increase speed by making it easier for browsers to map these associations in the Accessibility Tree.

Regarding the use of aria-posinset and aria-setsize, I agree that this isn't necessary. However, if these aren't included, then positioning data such as "1 of 6", "2 of 6", etc., won't actually be announced using both JAWS and NVDA in IE and Firefox equally, so it is useful at times for this purpose.

One of the primary problems with ARIA Menus that include both horizontal and vertical menus together at the same time, is that the horizontal and vertical aspects of these menus are not conveyed to screen reader users, so it is impossible for a blind screen reader user to know when pressing the Down arrow will navigate to another menu item at the same logical level, or if it will open a submenu instead, or if pressing the Right arrow will do the same, and so on with Up and Left. This is extremely confusing to a person who cannot see what the menus look like.

The same issue can be observed in a standard ARIA Menubar construct, where menuitems are represented from left to right, then pressing the Down arrow will open drop down submenus that are vertical, which then require a different mode of interaction to open submenus by using the Right arrow instead, none of which is conveyed to a blind screen reader user.

Currently the only way to deal with this at present is to either add offscreen text within the menuitem node that states which arrow press will open a submenu, or to include an aria-describedby attribute that does the same.

None of this will work well for mega-menu constructs however, because the nesting is too deep and this makes content very difficult to locate.

I recommend reading what Adobe has done to solve this problem, which is a good solution that is also an open source project that can be implemented by others for the same purpose.
Blog: http://blogs.adobe.com/accessibility/2013/05/adobe-com.html
Test: http://terrillthompson.com/tests/menus/accessible-mega-menu/test.html

From: Mallory van Achterberg
Date: Thu, Sep 04 2014 1:52AM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

On Wed, Sep 03, 2014 at 04:07:40PM -0700, Bryan Garaventa wrote:
> I understand your points, and those documenting the standards are aware of and do understand this problem as well, which isn't helped by the proliferation of outdated, half-correct, and incorrect data distributed across the web regarding ARIA that is publically accessible for all developers.
>
> If I may ask, did reading the training guide at
> http://whatsock.com/training/
> help at all? A little bit?

This is what a developer does:
1. has an existing problem/set of code or needs to build it
2. wants it to be accessible without breaking things for other users
3. reads all demos with these particular examples in mind

So every single example that any website anywhere gives, the developer
is reading those while thinking of the specific case in mind. Whenever
anything it quite different from the example, the developer starts to
make guesses, at least until they truly have understanding of the specs
or the technology.

I've seen more and more articles stating that it's "more intuitive" for
users if basic web interactive things "act like the desktop". Whose
desktop? Windows? And what about where the web has done it differently
and users who've used the web for the last 10 years and have been trained
very well by every website how to get from area to area? DO we pull the rug
out from under them?

I'm a keyboarder, and I tab (except when using Presto), because tab works.
It moves me to the next focusable thing without selecting it. Shift-tab
brings me back. The few few few exceptions are some form controls. Also the
web has had the very bad habit of styling buttons like links and links like
buttons, meaning lots of users like me tend to start out assuming it's a link
until proven otherwise. This means we use arrow keys to scroll the web page.
It means we tend to assume the buttony thingie will act like a link. It means
we don't try arrow keys and spacebars on these things (and we don't all
have a handy screen reader to tell us that that thing that looks like a button
actually *is* a button). When we devs keep in mind that the user might have
a screen reader or screen magnifier, we also need to remember we have users
who don't have these things.

Whenever there's an aria-something demo that suddenly starts using arrow
keys for visible, looks-like-they-can-be-focussed areas, that's pulling the
rug right out from under the sighted keyboarder. Is this so a screen reader
user can feel as if the webpage is a Windows application? Is this right?

The whatsock "menu" has form controls in it. The spec for the menuroles stuff
mentions controls a lot, talks about managing focus to the first control.
This is *atypical* for menus on the web. They don't tend to have form
controls. They don't tend to be applications. Most of the time, they're
navigation, and traditional navigation has been tabbable, and spacebar
has not "activated" anything traditionally. Spacebars are for buttons, radios,
checkboxes, but why would we think to use it on a menu? How would the sighted
user know there's a submenu if it doesn't appear on :focus? Why would we
think to hit space on something that has been, everywhere on the web, a link?
And what happens when you hit enter on a link? Why, you go to the resource.
So whether you click/hit enter on the link is going to be completely based
on whether you think you want to follow that link. Plus, as a developer you've
had "progressive enhancement" and "graceful degredation" harped on you like
in a church since way back when, so your menu links *should* have a
destination, because what if the user couldn't get the submenu to appear?

The fact that sites out there not implementing all the aria stuff acts one
way, and sites who do act a completely different way, means as a user
I'm ready to throw my computer out the window. As a dev, it means I'm *very*
reluctant to change web convention when I build something that's not some
totally-new widget (which I see aria as addressing best most of the time,
as these are indeed mostly taken from desktoppy applications and do not have
good HTML bases or semantics or default "web" behaviours users have been
trained to expect).

and...
The tab-panel example frustrated me because of course the one I was told
to build had to be quite different from teh whatsock version, meaning I
can't translate it enough to know if it's of any use to all users.

(more below)

>

From: Bryan Garaventa
Date: Thu, Sep 04 2014 2:42AM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

I understand all of your points, but most of these come down to education.

If a developer understands how ARIA works at the platform level including the Accessibility Tree, then it is easier to diagnose focus issues when they aren't being set to valid roles, how to recognize which attributes to use and when, how to test for these, and how these behaviors manifest in Assistive Technologies.

I have never claimed that all widgets are the same or that they should all use the same markup. What I have said, is that all widgets should be accessible from the keyboard, and that if ARIA is used as part of interactive widgets, that the roles need to match the paradigm for that widget.

ARIA is not platform specific, so to answer your question about which platform is valid, the answer is that the ARIA platform UI equivalent for a particular interactive widget is programmed by the user agent and Assistive Technology to match the platform UI equivalent on the OS that you are using at the time.

This is why you will get different feedback if you view the same control on Windows versus iOS on an iPhone or iPad, even though the markup is the same.

If you don't want to use ARIA, that is your choice, but choosing not to understand how it works is a different matter, and this limits your options. For example, if you want a Slider control to work properly using a drag and drop control with plain HTML and JavaScript, you must use ARIA to provide the correct feedback for screen reader users, otherwise this will not be accessible.

Education is important for screen reader users as well, and there should be more effort in this regard as part of this process as general usability training to understand how ARIA in particular is interacted with and what to expect.

I'm not sure what you mean that the ARIA Menus have form controls in them, these are triggered by a button which sets focus to an A tag that includes role=menuitem amongst all of the other requisite attributes, but there are no form controls within the menus. The Application role ensures that the correct modality will be enforced when JAWS is set within the menu after it opens, which is unreliable otherwise. The menus are programmed to act in the same manner as a standard context menu when you right click the web page, and the arrow keys are used to open or close submenus, not the Spacebar.

This is what I mean by education. If developers are aware of how such roles interact with the primary Assistive Technologies, and can thereby recognize when they are not being used correctly, it is then possible for them to modify the code accordingly in order to make these work. If developers have to guess all the time as you said, this will never work.

Additionally, when interactive widgets are programmed correctly and are verified by developers who understand these behaviors, then users have a responsibility to learn how these technologies are supposed to work, because these behaviors are not just the result of the developer, but are also programmed into the browser, and the Assistive Technology, in order to make them as accessible as possible within that platform. This is why ARIA exists. It is not just to make people's lives more difficult.

From: Bryan Garaventa
Date: Thu, Sep 04 2014 2:51AM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

A slight correction, it looks like the latest version of JAWS15 has regressed and no longer honors aria-posinset/aria-setsize in IE, so I'll need to file a bug. Also, I just noticed that JAWS no longer indicates selection on multiselect ARIA Listboxes. Two steps forward one step back, it always seems.

From: Sean Curtis
Date: Thu, Sep 04 2014 5:40AM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

After spending the last 9 months building an accessible dropdown menu component, I can say that none of the demos I found worked reliably in a variety of screen reader/browser combinations. In fact many seemed to have been developed to work in only say IE+JAWS, or NVDA+Firefox. Also many seemed to only include a subset of the available options for menus - eg links and radios, but not checkboxes or submenus. None included groups, or headings for them.

We built our menu up by spiking managing focus using aria-activedescendant and also by programmatically setting explicit focus. I was hoping using aria-activedescendant would work, however in our tests (JAWS, NVDA, VoiceOver using Chrome, Firefox, IE, Safari) it turned out that once you start using anything but plain old menuitems (links) the screen reader or browser (I'm not sure which is at fault for each case) support failed.

We defined a series of interactions, opening the dropdown, moving down through items, "activating" each item (using enter or space or special AT shortcuts like VO+Space which fires a click event) and then recording the feedback for each interaction, for each browser/screen reader combination. This was a long, painstakingly manual process. We ended up with 2 markup patterns, one which worked for JAWS and NVDA, the other for VoiceOver. We ended up OS sniffing (yes, I know) to switch between each pattern. It felt nasty at the time, but there is no way around it. When role="checkbox" works on one OS, but needs to be role="menuitemcheckbox" on the other, there's not much of an alternative.

We have nearly finished all our unit testing and documentation for this control. Hopefully I'll have time to blog about everything we learnt so others can benefit from it too. All I know is that the markup pattern ended up about twice as verbose as I was expecting. It is also a great deal more accessible than the other examples we found. It is only accessible in what is call the "good" browser+AT combinations (JAWS/NVDA + Firefox on Windows, and VO + Firefox/Chrome on OSX). Safari and IE failed some crucial interactions, no matter how hard we tried. I'll be creating reduced test cases to show these failures and then be raising a heap of bugs with the relevant browser or AT vendors.

Cheers,

Sean Curtis

> On 4 Sep 2014, at 6:51 pm, "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = > wrote:
>
> A slight correction, it looks like the latest version of JAWS15 has regressed and no longer honors aria-posinset/aria-setsize in IE, so I'll need to file a bug. Also, I just noticed that JAWS no longer indicates selection on multiselect ARIA Listboxes. Two steps forward one step back, it always seems.
>
>

From: Birkir R. Gunnarsson
Date: Thu, Sep 04 2014 6:50AM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

Shawn
Please make sure to post any demos or blogs regarding your experience
that you are allowed to share to this list.
ARIA is still a standard in the making.
We are relying on the markup to be applied correctly, for the browser
to interpret it correctly and map it to its accessibility API, the
various assistive technologies to access and interpret that
information and on the end user to understand what it means and how to
interact with it.
With the myriad of developers, browsers and assistive technologies we
have out there it gets tricky, don't get me started on end users, why
can't we standardize them. ;)

So all of you developers out there, please file your bugs, write your
thoughts and explain how ARIA helps or hinders your problems.
Though we have come a long way we are not nearly there yet.



On 9/4/14, Sean Curtis < = EMAIL ADDRESS REMOVED = > wrote:
> After spending the last 9 months building an accessible dropdown menu
> component, I can say that none of the demos I found worked reliably in a
> variety of screen reader/browser combinations. In fact many seemed to have
> been developed to work in only say IE+JAWS, or NVDA+Firefox. Also many
> seemed to only include a subset of the available options for menus - eg
> links and radios, but not checkboxes or submenus. None included groups, or
> headings for them.
>
> We built our menu up by spiking managing focus using aria-activedescendant
> and also by programmatically setting explicit focus. I was hoping using
> aria-activedescendant would work, however in our tests (JAWS, NVDA,
> VoiceOver using Chrome, Firefox, IE, Safari) it turned out that once you
> start using anything but plain old menuitems (links) the screen reader or
> browser (I'm not sure which is at fault for each case) support failed.
>
> We defined a series of interactions, opening the dropdown, moving down
> through items, "activating" each item (using enter or space or special AT
> shortcuts like VO+Space which fires a click event) and then recording the
> feedback for each interaction, for each browser/screen reader combination.
> This was a long, painstakingly manual process. We ended up with 2 markup
> patterns, one which worked for JAWS and NVDA, the other for VoiceOver. We
> ended up OS sniffing (yes, I know) to switch between each pattern. It felt
> nasty at the time, but there is no way around it. When role="checkbox" works
> on one OS, but needs to be role="menuitemcheckbox" on the other, there's not
> much of an alternative.
>
> We have nearly finished all our unit testing and documentation for this
> control. Hopefully I'll have time to blog about everything we learnt so
> others can benefit from it too. All I know is that the markup pattern ended
> up about twice as verbose as I was expecting. It is also a great deal more
> accessible than the other examples we found. It is only accessible in what
> is call the "good" browser+AT combinations (JAWS/NVDA + Firefox on Windows,
> and VO + Firefox/Chrome on OSX). Safari and IE failed some crucial
> interactions, no matter how hard we tried. I'll be creating reduced test
> cases to show these failures and then be raising a heap of bugs with the
> relevant browser or AT vendors.
>
> Cheers,
>
> Sean Curtis
>
>> On 4 Sep 2014, at 6:51 pm, "Bryan Garaventa"
>> < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> A slight correction, it looks like the latest version of JAWS15 has
>> regressed and no longer honors aria-posinset/aria-setsize in IE, so I'll
>> need to file a bug. Also, I just noticed that JAWS no longer indicates
>> selection on multiselect ARIA Listboxes. Two steps forward one step back,
>> it always seems.
>>
>>

From: Mallory van Achterberg
Date: Thu, Sep 04 2014 8:47AM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

On Thu, Sep 04, 2014 at 09:40:50PM +1000, Sean Curtis wrote:
> After spending the last 9 months building an accessible dropdown menu component, I can say that none of the demos I found worked reliably in a variety of screen reader/browser combinations. In fact many seemed to have been developed to work in only say IE+JAWS, or NVDA+Firefox. Also many seemed to only include a subset of the available options for menus - eg links and radios, but not checkboxes or submenus. None included groups, or headings for them.
>
> We built our menu up by spiking managing focus using aria-activedescendant and also by programmatically setting explicit focus. I was hoping using aria-activedescendant would work, however in our tests (JAWS, NVDA, VoiceOver using Chrome, Firefox, IE, Safari) it turned out that once you start using anything but plain old menuitems (links) the screen reader or browser (I'm not sure which is at fault for each case) support failed.
>
> We defined a series of interactions, opening the dropdown, moving down through items, "activating" each item (using enter or space or special AT shortcuts like VO+Space which fires a click event) and then recording the feedback for each interaction, for each browser/screen reader combination. This was a long, painstakingly manual process. We ended up with 2 markup patterns, one which worked for JAWS and NVDA, the other for VoiceOver. We ended up OS sniffing (yes, I know) to switch between each pattern. It felt nasty at the time, but there is no way around it. When role="checkbox" works on one OS, but needs to be role="menuitemcheckbox" on the other, there's not much of an alternative.
>
> We have nearly finished all our unit testing and documentation for this control. Hopefully I'll have time to blog about everything we learnt so others can benefit from it too. All I know is that the markup pattern ended up about twice as verbose as I was expecting. It is also a great deal more accessible than the other examples we found. It is only accessible in what is call the "good" browser+AT combinations (JAWS/NVDA + Firefox on Windows, and VO + Firefox/Chrome on OSX). Safari and IE failed some crucial interactions, no matter how hard we tried. I'll be creating reduced test cases to show these failures and then be raising a heap of bugs with the relevant browser or AT vendors.
>
> Cheers,
>
> Sean Curtis
>
Man, that sucks.
For "typical" webby dropdown menus, this is what I would hope hardest for:
1. that the suckerfish-style markup could generally be preserved. It's
clear, traditional and well-known to many users.
2. that if we use display: none to hide submenus (which I initially
didn't like now must use to preserve tabbing sanity with large subs),
that some small set of aria-roles/states and easily let the user know
that "ta-da! There is now a submenu available/visible!", and maybe even
when they leave that "the submenu is now gone!" if that's not too
verbose or unhelpful.
3. Javascripting to help interaction where pure CSS fails, which we all
already do.

Your tests are a bit devestating. :(

_mallory

From: Devarshi Pant
Date: Thu, Sep 04 2014 10:19AM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

Jordan,

This is intriguing. A few questions:

1. Is it possible to skip / go to specific sections?
2. What happens on tabbing?
3. Is page scrolling possible?

-devarshi
On Sep 2, 2014 2:25 PM, "Jordan Wilson" < = EMAIL ADDRESS REMOVED = >
wrote:

> A question about keyboard navigation using arrow-only navigation instead
> of tabbing. Is that at all acceptable? A client site has good keyboard
> navigation if you use the arrow keys alone and they inform users that their
> site is optimized to be used that way. Unfortunately the site doesn't work
> at all with standard tabbing through content.
>
> I'm assuming that isn't acceptable, but since the arrow key navigation is
> actually quite good it seems intentional. They clearly spent a lot of time
> and effort ensuring the arrow navigation, so I figured I'd ask the
> community.
> > > >

From: Bryan Garaventa
Date: Thu, Sep 04 2014 10:35AM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

Thanks, that info will help a lot, and please do file bugs.

Much of this is the result of how the ARIA widget markup is handled by the browser/AT combination on the OS, so this doesn't surprise me at all. For instance you can run the same code on the iPad using Safari and get different results on the Android with Chrome, or even using IE versus Chrome on Windows using differing screen readers.

I'm glad this testing is being done elsewhere too, so that differences can be shored up in the future.

All the best,
Bryan

From: Wyant, Jay (MNIT)
Date: Thu, Sep 04 2014 11:26AM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

This conversation highlights, to me, the need for:
- publicly available, reusable pattern libraries
- fervent bug reporting to AT manufacturers

As much as we all want accessibility to work, when executives look at the price Atlassian paid for 9 months of work to make a dropdown menu (add up development hours, testing hours, debugging hours, and pretty soon you get into real money) many are going to decide it isn't worth it. So we need to make sure that future efforts can build upon Michael's and Sean's work and Bryan's bug reports and all other related work.

Jay

From: Sean Curtis
Date: Thu, Sep 04 2014 3:08PM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

> - publicly available, reusable pattern libraries

While this would have certainly helped get us most of the way there, it wouldn't have helped with the JavaScript. Toggling the menu via display none and then setting focus on the first item required using setTimeout (yes, I know) with a delay of about 50ms. Anything less and the screen reader wouldn't read the contents of the item. I think it has something to so with the repaint of the menu. That delay might also need to change depending on the speed of the machine (how fast it repaints). I haven't tried too many slow machines, only the old (purposely) windows laptop I have for testing.

Cheers,

Sean Curtis

From: Sean Curtis
Date: Thu, Sep 04 2014 3:16PM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

Also, I didn't intend for me earlier reply to dissuade people from making dropdown menus accessible. For a simple menu (no radios, checkboxes, group headings or submenus) using both aria-activedescendant and explicit focus (if probably recommend aria-activedescendant) performed well in most of the browser-AT combos. The markup pattern was also quite simple and didn't need to change between Win and OSX.

Cheers,

Sean

> On 5 Sep 2014, at 3:26 am, "Wyant, Jay (MNIT)" < = EMAIL ADDRESS REMOVED = > wrote:
>
> This conversation highlights, to me, the need for:
> - publicly available, reusable pattern libraries
> - fervent bug reporting to AT manufacturers
>
> As much as we all want accessibility to work, when executives look at the price Atlassian paid for 9 months of work to make a dropdown menu (add up development hours, testing hours, debugging hours, and pretty soon you get into real money) many are going to decide it isn't worth it. So we need to make sure that future efforts can build upon Michael's and Sean's work and Bryan's bug reports and all other related work.
>
> Jay
>
>

From: Stanzel, Susan - FSA, Kansas City, MO
Date: Fri, Sep 05 2014 6:16AM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

After all this conversation, could the author of a working dropdown menu please send the coding required?


Susie Stanzel

From: Sean Curtis
Date: Fri, Sep 05 2014 7:59AM
Subject: Re: Keyboard navigation using arrows only
← Previous message | Next message →

Hi Suzie,

I'm working on a concise demo. I'll try and get something live next week.

Cheers,

Sean

> On 5 Sep 2014, at 10:16 pm, "Stanzel, Susan - FSA, Kansas City, MO" < = EMAIL ADDRESS REMOVED = > wrote:
>
> After all this conversation, could the author of a working dropdown menu please send the coding required?
>
>
> Susie Stanzel
>

From: Stanzel, Susan - FSA, Kansas City, MO
Date: Fri, Sep 05 2014 10:12AM
Subject: Re: Keyboard navigation using arrows only
← Previous message | No next message

Thank you very much. This list is very helpful. I am the assistant Section 508 person and forward many of these important messages to Steve Meacham, our lead Section 508.

Susie Stanzel