← 6.5 System state and capabilitiesTable of contents7.6.4 Editing APIs →
  1. 7 User interaction
    1. 7.1 The hidden attribute
    2. 7.2 Inert subtrees
    3. 7.3 Activation
    4. 7.4 Focus
      1. 7.4.1 Sequential focus navigation and the tabindex attribute
      2. 7.4.2 Document-level focus APIs
      3. 7.4.3 Element-level focus APIs
    5. 7.5 Assigning keyboard shortcuts
      1. 7.5.1 Introduction
      2. 7.5.2 The accesskey attribute
    6. 7.6 Editing
      1. 7.6.1 Making document regions editable: The contenteditable content attribute
      2. 7.6.2 Making entire documents editable: The designMode IDL attribute
      3. 7.6.3 Best practices for in-page editors

7 User interaction

7.1 The hidden attribute

All HTML elements may have the hidden content attribute set. The hidden attribute is a boolean attribute. When specified on an element, it indicates that the element is not yet, or is no longer, directly relevant to the page's current state, or that it is being used to declare content to be reused by other parts of the page as opposed to being directly accessed by the user.

In the following skeletal example, the attribute is used to hide the Web game's main screen until the user logs in:

  <h1>The Example Game</h1>
  <section id="login">
   <h2>Login</h2>
   <form>
    ...
    <!-- calls login() once the user's credentials have been checked -->
   </form>
   <script>
    function login() {
      // switch screens
      document.getElementById('login').hidden = true;
      document.getElementById('game').hidden = false;
    }
   </script>
  </section>
  <section id="game" hidden>
   ...
  </section>

The hidden attribute must not be used to hide content that could legitimately be shown in another presentation. For example, it is incorrect to use hidden to hide panels in a tabbed dialog, because the tabbed interface is merely a kind of overflow presentation — one could equally well just show all the form controls in one big page with a scrollbar. It is similarly incorrect to use this attribute to hide content just from one presentation — if something is marked hidden, it is hidden from all presentations, including, for instance, screen readers.

Elements that are not themselves hidden must not hyperlink to elements that are hidden. The for attributes of label and output elements that are not themselves hidden must similarly not refer to elements that are hidden. In both cases, such references would cause user confusion.

Elements and scripts may, however, refer to elements that are hidden in other contexts.

For example, it would be incorrect to use the href attribute to link to a section marked with the hidden attribute. If the content is not applicable or relevant, then there is no reason to link to it.

It would be fine, however, to use the ARIA aria-describedby attribute to refer to descriptions that are themselves hidden. While hiding the descriptions implies that they are not useful alone, they could be written in such a way that they are useful in the specific context of being referenced from the images that they describe.

Similarly, a canvas element with the hidden attribute could be used by a scripted graphics engine as an off-screen buffer, and a form control could refer to a hidden form element using its form attribute.

Accessibility APIs are encouraged to provide a way to expose structured content while marking it as hidden in the default view. Such content should not be perceivable to users in the normal document flow in any modality, whether using Assistive Technology (AT) or mainstream User Agents.

When such features are available, User Agents may use them to expose the full semantics of hidden elements to AT when appropriate, if such content is referenced indirectly by an ID reference or valid hash-name reference. This allows ATs to access the structure of these hidden elements upon user request, while keeping the content hidden in all presentations of the normal document flow. Authors who wish to prevent user-initiated viewing of a hidden element should not reference the element with such a mechanism.

Because some User Agents have flattened hidden content when exposing such content to AT, authors should not reference hidden content which would lose essential meaning when flattened.

For example, it would be appropriate for the structure of hidden table headers referenced from a headers attribute to be exposed to users of AT with such an API.

Cases where it would be inappropriate for the structure of hidden elements to be exposed to users of AT with such an API include:

Specifications which define elements and attributes which may be included in conforming HTML5 documents (such as SVG, MathML, and WAI-ARIA) may define how or whether this applies to their elements and attributes. [ARIA] [MATHML] [SVG]

Elements in a section hidden by the hidden attribute are still active, e.g. scripts and form controls in such sections still execute and submit respectively. Only their presentation to the user changes.

7.2 Inert subtrees

A subtree of a Document can be marked as inert. When a node or one of its ancestors is inert, then the user agent must act as if the element was absent for the purposes of targetting user interaction events, may ignore the node for the purposes of text search user interfaces (commonly known as "find in page"), and may prevent the user from selecting text in that node. User agents should allow the user to override the restrictions on search and text selection, however.

For example, consider a page that consists of just a single inert paragraph positioned in the middle of a body. If a user moves their pointing device from the body over to the inert paragraph and clicks on the paragraph, no mouseover event would be fired, and the mousemove and click events would be fired on the body element rather than the paragraph.

When a node or one of its ancestors is inert, it also can't be focused (see the focusing steps), and it is disabled if it is a command.

An entire Document can be marked as blocked by a modal dialog dialog. While a Document is so marked, every node that is in the Document, with the exception of the dialog element, its ancestors, and its descendants, must be marked inert. (The elements excepted by this paragraph can additionally be marked inert through other means; being part of a modal dialog does not "protect" a node from being marked inert.)

Only one element at a time can mark a Document as being blocked by a modal dialog. When a new dialog is made to block a Document, the previous element, if any, stops blocking the Document.

The dialog element's showModal() method makes use of this mechanism.

7.3 Activation

element . click()

Acts as if the element was clicked.

7.4 Focus

7.4.1 Sequential focus navigation and the tabindex attribute

The tabindex content attribute allows authors to control whether an element is supposed to be focusable, whether it is supposed to be reachable using sequential focus navigation, and what is to be the relative order of the element for the purposes of sequential focus navigation. The name "tab index" comes from the common use of the "tab" key to navigate through the focusable elements. The term "tabbing" refers to moving forward through the focusable elements that can be reached using sequential focus navigation.

The tabindex attribute, if specified, must have a value that is a valid integer.

7.4.2 Document-level focus APIs

document . activeElement

Returns the currently focused element.

document . hasFocus()

Returns true if the document has focus; otherwise, returns false.

window . focus()

Focuses the window. Use of this method is discouraged. Allow the user to control window focus instead.

window . blur()

Unfocuses the window. Use of this method is discouraged. Allow the user to control window focus instead.

7.4.3 Element-level focus APIs

element . focus()

Focuses the element.

element . blur()

Unfocuses the element. Use of this method is discouraged. Focus another element instead.

Do not use this method to hide the focus ring. Do not use any other method that hides the focus ring from keyboard users,in particluar do not use a CSS rule to override the 'outline' property. Removal of the focus ring leads to serious accessibility issues for users who navigate and interact with interactive content using the keyboard.

7.5 Assigning keyboard shortcuts

7.5.1 Introduction

This section is non-normative.

Each element that can be activated or focused can be assigned a single key combination to activate it, using the accesskey attribute.

The exact shortcut is determined by the user agent, based on information about the user's keyboard, what keyboard shortcuts already exist on the platform, and what other shortcuts have been specified on the page, using the information provided in the accesskey attribute as a guide.

In order to ensure that a relevant keyboard shortcut is available on a wide variety of input devices, the author can provide a number of alternatives in the accesskey attribute.

Each alternative consists of a single character, such as a letter or digit.

User agents can provide users with a list of the keyboard shortcuts, but authors are encouraged to do so also. The accessKeyLabel IDL attribute returns a string representing the actual key combination assigned by the user agent.

In this example, an author has provided a button that can be invoked using a shortcut key. To support full keyboards, the author has provided "C" as a possible key. To support devices equipped only with numeric keypads, the author has provided "1" as another possibly key.

<input type=button value=Collect onclick="collect()"
       accesskey="C 1" id=c>

To tell the user what the shortcut key is, the author has this script here opted to explicitly add the key combination to the button's label:

function addShortcutKeyLabel(button) {
  if (button.accessKeyLabel != '')
    button.value += ' (' + button.accessKeyLabel + ')';
}
addShortcutKeyLabel(document.getElementById('c'));

Browsers on different platforms will show different labels, even for the same key combination, based on the convention prevalent on that platform. For example, if the key combination is the Control key, the Shift key, and the letter C, a Windows browser might display "Ctrl+Shift+C", whereas a Mac browser might display "^⇧C", while an Emacs browser might just display "C-C". Similarly, if the key combination is the Alt key and the Escape key, Windows might use "Alt+Esc", Mac might use "⌥⎋", and an Emacs browser might use "M-ESC" or "ESC ESC".

In general, therefore, it is unwise to attempt to parse the value returned from the accessKeyLabel IDL attribute.

7.5.2 The accesskey attribute

All HTML elements may have the accesskey content attribute set. The accesskey attribute's value is used by the user agent as a guide for creating a keyboard shortcut that activates or focuses the element.

If specified, the value must be an ordered set of unique space-separated tokens that are case-sensitive, each of which must be exactly one Unicode code point in length.

In the following example, a variety of links are given with access keys so that keyboard users familiar with the site can more quickly navigate to the relevant pages:

<nav>
 <p>
  <a title="Consortium Activities" accesskey="A" href="/Consortium/activities">Activities</a> |
  <a title="Technical Reports and Recommendations" accesskey="T" href="/TR/">Technical Reports</a> |
  <a title="Alphabetical Site Index" accesskey="S" href="/Consortium/siteindex">Site Index</a> |
  <a title="About This Site" accesskey="B" href="/Consortium/">About Consortium</a> |
  <a title="Contact Consortium" accesskey="C" href="/Consortium/contact">Contact</a>
 </p>
</nav>

In the following example, the search field is given two possible access keys, "s" and "0" (in that order). A user agent on a device with a full keyboard might pick Ctrl+Alt+S as the shortcut key, while a user agent on a small device with just a numeric keypad might pick just the plain unadorned key 0:

<form action="/search">
 <label>Search: <input type="search" name="q" accesskey="s 0"></label>
 <input type="submit">
</form>

In the following example, a button has possible access keys described. A script then tries to update the button's label to advertise the key combination the user agent selected.

<input type=submit accesskey="N @ 1" value="Compose">
...
<script>
 function labelButton(button) {
   if (button.accessKeyLabel)
     button.value += ' (' + button.accessKeyLabel + ')';
 }
 var inputs = document.getElementsByTagName('input');
 for (var i = 0; i < inputs.length; i += 1) {
   if (inputs[i].type == "submit")
     labelButton(inputs[i]);
 }
</script>

On one user agent, the button's label might become "Compose (⌘N)". On another, it might become "Compose (Alt+⇧+1)". If the user agent doesn't assign a key, it will be just "Compose". The exact string depends on what the assigned access key is, and on how the user agent represents that key combination.

7.6 Editing

7.6.1 Making document regions editable: The contenteditable content attribute

The contenteditable attribute is an enumerated attribute whose keywords are the empty string, true, and false. The empty string and the true keyword map to the true state. The false keyword maps to the false state. In addition, there is a third state, the inherit state, which is the missing value default (and the invalid value default).

The true state indicates that the element is editable. The inherit state indicates that the element is editable if its parent is. The false state indicates that the element is not editable.

element . contentEditable [ = value ]

Returns "true", "false", or "inherit", based on the state of the contenteditable attribute.

Can be set, to change that state.

Throws a SyntaxError exception if the new value isn't one of those strings.

element . isContentEditable

Returns true if the element is editable; otherwise, returns false.

7.6.2 Making entire documents editable: The designMode IDL attribute

document . designMode [ = value ]

Returns "on" if the document is editable, and "off" if it isn't.

Can be set, to change the document's current state.

7.6.3 Best practices for in-page editors

Authors are encouraged to set the 'white-space' property on editing hosts and on markup that was originally created through these editing mechanisms to the value 'pre-wrap'. Default HTML whitespace handling is not well suited to WYSIWYG editing, and line wrapping will not work correctly in some corner cases if 'white-space' is left at its default value.

As an example of problems that occur if the default 'normal' value is used instead, consider the case of the user typing "yellow&blank;&blank;ball", with two spaces (here represented by "&blank;") between the words. With the editing rules in place for the default value of 'white-space' ('normal'), the resulting markup will either consist of "yellow&nbsp; ball" or "yellow &nbsp;ball"; i.e., there will be a non-breaking space between the two words in addition to the regular space. This is necessary because the 'normal' value for 'white-space' requires adjacent regular spaces to be collapsed together.

In the former case, "yellow⍽" might wrap to the next line ("⍽" being used here to represent a non-breaking space) even though "yellow" alone might fit at the end of the line; in the latter case, "⍽ball", if wrapped to the start of the line, would have visible indentation from the non-breaking space.

When 'white-space' is set to 'pre-wrap', however, the editing rules will instead simply put two regular spaces between the words, and should the two words be split at the end of a line, the spaces would be neatly removed from the rendering.