Proposal to extend the support of aria-orientation

This is something that came up during the last APG call, so I'd like to float this here before filing a spec issue for it to get peoples' view on it.

Currently the scope of aria-orientation is very limited, E.G
http://www.w3.org/TR/wai-aria/states_and_properties#aria-orientation

The problem is that there are specific areas where this would be very useful, if not necessary, and there is currently no support for these implementations.

The first example has to do with menu constructs.

Menus don't always fall into the category of horizontal Menubar and vertical Menu only, but can be represented in different ways depending on the styling of the menu.

For example, a menu, triggered by an active element as a layer, may be represented horizontally as a flyout menu, and may switch between vertical and horizontal styling as is typically seen within megamenu constructs. When this is done, the keyboard interaction model is customized to fit the display, so that pressing the Right arrow will move to the next menu item in a horizontal flyout menu, or may open a submenu in a vertical menu, depending on how the menu is styled and implemented.

The problem from an AT perspective, is that there is no way to convey these differences, making it impossible for non-sighted screen reader users to know which keyboard interaction model is applied, because they can't see the styling of the menu. The assumption then is that all menus are vertical, which is incorrect and misleading to the user.

The availability of aria-orientation for the role of Menu would solve this however, allowing ATs to correctly convey this information to the user, regardless whether the container element received focus or the child menu item node for that widget.

The same is true for Tree constructs, where a tree may be represented as a downward facing branch instead of a left to right facing branch, so that the Down arrow is used to expand branch nodes instead of the Right arrow as is typically seen. This too would be a good candidate for knowing what the orientation is designed to do, in order to provide the correct feedback.

There may be other widget roles where this may be useful as well, but hopefully this outlines the importance of having this functionality be extended for better use and support.

Received on Wednesday, 10 December 2014 20:11:11 UTC