Skip to main content
WCAGrules
Quick navigation

ARIA property

aria-orientation

Whether a widget runs horizontally or vertically, which decides which arrow keys move through it.

It tells people which arrow keys to expect. It does not wire them up. Change the value and the announcement changes, while the key handling stays exactly where you left it.

Which roles may carry aria-orientation

Value
token
Filed as
A property, which is how ARIA files it and not a rule about how often it changes.
Roles that may carry it
scrollbar, select, separator, slider, tablist, toolbar
Roles that inherit it
listbox, menu, menubar, radiogroup, tree, treegrid

Those lists are not advice. Browsers are required to ignore a non-global attribute sitting on a role that does not support it, so aria-orientation on the wrong element is not weak, it is absent. You can read it in the DOM and nobody using a screen reader can.

Every role above comes from the specification's own list for this attribute, checked name for name. The normative definition stays with the W3C, in the aria-orientation section of the ARIA specification.

Keeping aria-orientation true

The value and the key handling have to agree, and the default is less obvious than it looks. Before ARIA 1.1 the default was horizontal. It is now undefined, with each role bringing its own instead. A slider is horizontal, a scrollbar is vertical, a menubar is horizontal, a menu is vertical, a tablist is horizontal. So leaving the attribute off is fine when you match the role's default and a real problem when you do not. A vertical tab list that never says so is telling everybody to press left and right.

How aria-orientation gets checked

There are test rules that check an ARIA attribute is one that exists, is allowed on the role underneath it, and carries a value of the right type. What they map to is ARIA's own author requirements rather than any WCAG criterion, so a misplaced attribute breaks ARIA without being a WCAG failure by itself. It becomes one under 4.1.2 Name, Role, Value the moment the missing or wrong value means the control's state cannot be worked out programmatically, which is what usually happens next.

Nothing automated catches the failure this page is about. A stale value is a valid value, on a permitted role, with the right type. It is only wrong about the world.

Attributes you will meet alongside aria-orientation

  • aria-disabled Says a control is present but not available. Unlike the disabled attribute, it stays focusable, so people can still find out it is there.
  • aria-errormessage Points at the message explaining why this field is invalid. Only meaningful while aria-invalid is set.
  • aria-haspopup Says this control opens something, and what kind of thing it opens. A menu, a dialog, a listbox.
  • aria-invalid Says a field's value has failed validation.
  • aria-multiselectable Whether more than one option can be chosen at once.
  • aria-readonly The value can be read but not changed. Unlike disabled, it is still part of the form.
  • aria-valuemax The highest value a range control accepts.
  • aria-valuemin The lowest value a range control accepts.

Every ARIA state and property · Every ARIA role · ARIA explained

Go somewhere useful

Find tools, resources and your workspace.

29 destinations