SVG content can be interactive (i.e., responsive to user-initiated events) by utilizing the following features in the SVG language:

13.2 Complete list of supported events

The following table lists all of the events which must be recognized and supported in SVG. The "Description" column describes the required conditions for the event to occur.

Event Type	Description	Animation event name	Bubbles	Cancelable	uDOM interface
DOMFocusIn	Occurs when an element receives focus. See the DOM 2 Events definition of DOMFocusIn ([DOM2EVENTS], section 1.6.1).	focusin	Yes	No	UIEvent
DOMFocusOut	Occurs when an element loses focus. See the DOM 2 Events definition of DOMFocusOut ([DOM2EVENTS], section 1.6.1).	focusout	Yes	No	UIEvent
DOMActivate	Occurs when an element is activated, for instance, through a mouse click or a keypress. See the DOM 2 Events definition of DOMActivate ([DOM2EVENTS], section 1.6.1).	activate	Yes	Yes	UIEvent
click	Occurs when the pointing device button is clicked over an element. A click is defined as a mousedown and mouseup over the same screen location. The sequence of these events is: `mousedown`, `mouseup`, `click`. If multiple clicks occur at the same screen location, the sequence repeats with the `detail` attribute incrementing with each repetition. See the DOM 2 Events definition of click ([DOM2EVENTS], section 1.6.2).	click	Yes	Yes	MouseEvent
mousedown	Occurs when the pointing device button is pressed over an element. See the DOM 2 Events definition of mousedown ([DOM2EVENTS], section 1.6.2).	mousedown	Yes	Yes	MouseEvent
mouseup	Occurs when the pointing device button is released over an element. See the DOM 2 Events definition of mouseup ([DOM2EVENTS], section 1.6.2).	mouseup	Yes	Yes	MouseEvent
mouseover	Occurs when the pointing device is moved onto an element. See the DOM 2 Events definition of mouseover ([DOM2EVENTS], section 1.6.2).	mouseover	Yes	Yes	MouseEvent
mousemove	Occurs when the pointing device is moved while it is over an element. See the DOM 2 Events definition of mousemove ([DOM2EVENTS], section 1.6.2).	mousemove	Yes	Yes	MouseEvent
mouseout	Occurs when the pointing device is moved away from an element. See the DOM 2 Events definition of mouseout ([DOM2EVENTS], section 1.6.2).	mouseout	Yes	Yes	MouseEvent
mousewheel	Occurs when a rotational input device has been activated. See the description of the MouseWheelEvent event for details.	none	Yes	Yes	MouseWheelEvent
textInput	One or more characters have been entered. See the Text events section below for details.	none	Yes	Yes	TextEvent
keydown	A key is pressed down. See the Key events section below for details.	none	Yes	Yes	KeyboardEvent
keyup	A key is released. See the Key events section below for details.	none	Yes	Yes	KeyboardEvent
load	The event is triggered at the point at which the user agent finishes loading the element and any dependent resources (such as images, style sheets, or scripts). In the case the element references a script, the event will be raised only after an attempt to interpret the script has been made. Dependent resources that fail to load will not prevent this event from firing if the element that referenced them is still in the document tree unless they are designated as externalResourcesRequired. The event is independent of the means by which the element was added to DOM tree.	load	No	No	Event
SVGLoad	This event is deprecated and is for backwards compatibility only, see notes below. The This event must be dispatched immediately after the load event is dispatched.	none	No	No	Event
resize	Occurs when a document view is being resized. This event is only applicable to 'svg' elements and is dispatched after the resize operation has taken place. The target of the event is the 'svg' element.	resize	Yes	No	Event
SVGResize	This event is deprecated and is for backwards compatibility only, see notes below. This event must be dispatched immediately after the resize event is dispatched.	none	Yes	No	Event
scroll	Occurs when a document view is being shifted along the X or Y or both axis, either through a direct user interaction or any change on the `currentTranslate` property available on SVGSVGElement interface. This event is only applicable to 'svg' elements and is dispatched after the shift modification has taken place. The target of the event is the 'svg' element.	scroll	Yes	No	Event
SVGScroll	This event is deprecated and is for backwards compatibility only, see notes below. This event must be dispatched immediately after the scroll event is dispatched.	none	Yes	No	Event
SVGZoom	Occurs when the zoom level of a document view is being changed, either through a direct user interaction or any change to the `currentScale` property available on SVGSVGElement interface. This event is only applicable to 'svg' elements and is dispatched after the zoom level modification has taken place. The target of the event is the 'svg' element.	zoom	No	No	Event
SVGRotate	Occurs when the rotation of a document view is being changed, either through a direct user interaction or any change to the `currentRotate` property available on SVGSVGElement interface. This event is only applicable to 'svg' elements and is dispatched after the rotation modification has taken place. The target of the event is the 'svg' element.	rotate	No	No	Event
beginEvent	Occurs when a timed element begins. See the SMIL 2.1 definition of beginEvent ([DOM2EVENTS], section 10.6.2).	beginEvent	Yes	No	TimeEvent
endEvent	Occurs when a timed element ends. See the SMIL 2.1 definition of endEvent ([DOM2EVENTS], section 10.6.2).	endEvent	Yes	No	TimeEvent
repeatEvent	Occurs when a timed element repeats. It is raised each time the element repeats, after the first iteration. See the SMIL 2.1 definition of repeatEvent ([DOM2EVENTS], section 10.6.2).	repeatEvent	Yes	No	TimeEvent
loadstart	A load operation has begun. See the description of the ProgressEvent interface for details on this event.	none	No	No	ProgressEvent
progress	Progress has occurred in loading a given resource. See the description of the ProgressEvent interface for details on this event.	none	No	No	ProgressEvent
loadend	A load operation has completed. See the description of the ProgressEvent interface for details on this event.	none	No	No	ProgressEvent
SVGTimer	Occurs when the specified timer interval has elapsed for a timer. This event is triggered only by 'running' timers in the current global execution context of the SVG document (i.e. for timers which have been instantiated via the SVGGlobal interface and started via the `start()` method of the SVGTimer interface). The target of the event is the SVGTimer object itself. The event processing is limited to the at target phase. See the description of the SVGTimer interface for more details.	none	No	No	Event

Note that in order to unify event names with other W3C specifications, SVG Tiny 1.2 deprecates some of the SVG 1.1 event types. (The term "deprecate" in this case means that user agents which are compatible with both SVG 1.1 and SVG Tiny 1.2 must support both the old deprecated event names and the new event names. Content creators who are making content that targets SVG Tiny 1.2 should use the new event types, not the deprecated event types.) Specifically:

Details on the values of attributes on the event object passed to event listeners for the event types defined in DOM Level 2 Events can be found in the description for that event in that specification. For other event types, the values of the attributes are are described elsewhere in this specification.

13.3 User interface events

On SVG user agents which support interactivity, it is common for authors to define SVG documents such that they are responsive to user interface events. Among the set of possible user events are pointer events, keyboard events, and document events.

In response to user interface (UI) events, the author might start an animation, perform a hyperlink to another Web page, highlight part of the document (e.g. change the color of the graphics elements which are under the pointer), initiate a "roll-over" (e.g., cause some previously hidden graphics elements to appear near the pointer) or launch a script which communicates with a remote database.

The following example shows the use of a DOMActivate event to trigger an ECMAScript event handler:

13.4 Pointer events

Note: The W3C's Web Content Accessibility Guidelines (WCAG) advise content creators to create device-independent content; in particular, content should not require that the user has access to a pointer device.

User interface events that occur because of user actions performed on a pointer device are called pointer events.

Many systems support pointer devices such as a mouse, trackball, stylus or joypad. On systems which use a mouse, pointer events consist of actions such as mouse movements and mouse clicks. On systems with a different pointer device, the pointing device often emulates the behavior of the mouse by providing a mechanism for equivalent user actions, such as a button to press which is equivalent to a mouse click.

One difference between stylus-based pointers and mouse-based pointers is that for a mouse, the cursor always has a position; for a stylus which may be lifted, the cursor may only have a position when the stylus is tapped on the screen. Thus, content which assumes that all pointer devices will generate mouseover and mouseout events will not work on all devices.

13.5 Text events

User interface events that occur because of user actions that generate text are called text events. They are usually generated by a keyboard, but can also be generated by a different input method such as an IME (for Japanese text, for example), by speech input, etc. The event is dispatched whenever a string of Unicode characters is sent to the document and is thus independent of the input device or method used.

13.6 Key events

User interface events that occur because of user actions that generate key presses (as opposed to text — for example, function keys, key presses for a game, etc.) are called key events.

13.7 Event flow

DOM Level 2 Events defines the event flow model ([DOM2EVENTS], section 1.2), which defines three phases in which event listeners in the document are triggered: capture, at target and bubbling. An SVG Tiny 1.2 user agent is not required to support the capture phase of the event flow model. If the capture phase is not supported:

13.8 Event dispatching

For each pointer event, text event or key event, the SVG user agent determines the target object of a given event. The target object must be the topmost graphics element or SVGElementInstance object whose relevant graphical content is under the pointer (for pointer events) or has focus (for text and key events) at the time of the event. (See property 'pointer-events' for a description of how to determine whether an element's relevant graphical content is under the pointer, and thus in which circumstances that graphics element can be the target object for a pointer event.) When an element is not displayed (i.e., when the 'display' property on that element or one of its ancestors has a value of none), that element must not be the target of pointer events.

The decision on whether to dispatch the event to the target object or to one of the target elements ancestors shall depend on the following:

If an event is defined to bubble ([DOM2EVENTS], section 1.2.3), bubbling occurs up to all direct ancestors of the target object. Descendant elements receive events before their ancestors. Thus, if a 'path' element is a child of a 'g' element and they both have event listeners for click events, then the event will be dispatched to the 'path' element before the 'g' element.

After an event is initially dispatched to a particular element, unless an appropriate action has been taken to prevent further processing, the event must be passed to the appropriate event handlers (if any) for that element's ancestors (in the case of event bubbling) for further processing.

13.9 Processing order for user interface events

The 'use' element creates shadow content which can be the target of user interface events.

User interface events within the shadow content shall participate in the processing of user interface events in the same manner as if the shadow content were part of the main document. In other words, if shadow content contains a graphics element that renders above other content at the current pointer location, then it represents the topmost graphics element and will receive the pointer events before other elements. In this case, the user interface events bubble up through the target's ancestors, and then across the document border into the referencing element, and then through the ancestors of the referencing element. This process continues as necessary if there are multiple levels of nested shadow trees.

13.10 The 'pointer-events' property

In different circumstances, authors may want to control under what circumstances particular graphics element can become the target of pointer events. For example, the author might want a given element to receive pointer events only when the pointer is over the stroked perimeter of a given shape. In other cases, the author might want a given element to ignore pointer events under all circumstances so that graphics elements underneath the given element will become the target of pointer events.

For example, suppose a 'circle' with a 'stroke' of red (i.e., the outline is solid red) and a 'fill' of none (i.e., the interior is not painted) is rendered directly on top of a 'rect' with a 'fill' of blue. The author might want the 'circle' to be the target of pointer events only when the pointer is over the perimeter of the 'circle'. When the pointer is over the interior of the 'circle', the author might want the underlying 'rect' to be the target element of pointer events.

The 'pointer-events' property specifies under what circumstances a given graphics element can be the target element for a pointer event. It affects the circumstances under which the following are processed:

For raster images, hit detection shall either be performed on a whole-image basis (i.e., the rectangular area for the image is one of the determinants for whether the image receives the event) or on a per-pixel basic (i.e., the alpha values for pixels under the pointer help determine whether the image receives the event). The following rules must be adhered to:

13.11 Magnification and panning

Magnification represents a complete, uniform transformation on an SVG document fragment, where the magnify operation scales all graphical elements by the same amount. A magnify operation has the effect of a supplemental scale and translate transformation placed at the rootmost level on the SVG document fragment (i.e. outside the rootmost 'svg' element).

Panning represents a translation (i.e., a shift) transformation on an SVG document fragment in response to a user interface action.

SVG user agents that operate in interaction-capable user environments are required to support the ability to magnify and pan.

13.12 Element focus

13.12.1 The 'focusable' attribute

In many cases, such as text editing, the user is required to place focus on a particular element, ensuring that input events, such as keyboard input, are sent to that element.

Attribute definition:

focusable = "true" | "false" | "auto"

Defines if an element can get keyboard focus (i.e. receive keyboard events) and be a target for field-to-field navigation actions. (Note: in some environments, field-to-field navigation can be accomplished with the tab key.)

The attribute value can be one of the following:

true

The element is keyboard-aware and must be treated as any other UI component that can get focus.

false

The element is not focusable.

auto

The lacuna value. Equivalent to 'false', except that it must be treated like 'true' for the following cases:

The 'a' element.
Text content block elements with 'editable' set to 'simple'.
Elements that are the target of an animation whose begin or end lists include an eventbase timing specifier triggered by the following user interface events: DOMFocusIn, DOMFocusOut, DOMActivate.
Elements that have an event listener registered on one of the following user interface events: DOMFocusIn, DOMFocusOut, DOMActivate.

Informative note: Event listeners for the listed events can be added to elements that are the 'target' or 'observer' of a 'listener' element, the parent element of a 'handler' element if it has an 'ev:event' attribute as well as by using script.

Animatable: yes.

13.13 Navigation

13.13.1 Navigation behavior

System-dependent input facilities (e.g., the tab key on most desktop computers) should be supported to allow navigation between elements that can obtain focus (i.e. elements for which the value of the 'focusable' attribute is 'true').

The document has the concept of a focus ring, which is the order in which elements obtain focus. By default the focus ring shall be obtained using document order. All focusable elements must be part of the default focus ring. A document's focus ring includes any focusable objects within shadow trees for 'use' elements. The focus attributes may be used to modify the default focus ring.

The SVG language supports a flattened notion of field navigation between focusable elements where an author may define field navigation between any two focusable elements defined within a given SVG document without regard to document hierarchy. For example:

In the above example, the author may specify field-to-field navigation such the user can navigate directly from any of the three elements. Thus, assuming a desktop computer which uses the tab key for field navigation, the author may specify focus navigation order such that the tab key takes the user from "r1" to "c1" to "g1".

When navigating to an element that is not visible on the canvas the following rules shall apply:

SVG's flattened notion of field navigation shall extend to referenced content and shadow trees as follows:

For stand-alone SVG documents, the SVG user agent must always have a currently focused object. If focus is not held by any object in the document tree, the SVG user agent must give focus to the SVGDocument object.

For SVG documents which are referenced by a non-SVG host document (e.g., XHTML), the SVG document may participate within the host document's focus ring, which would allow direct navigation from an SVG focusable element onto a focusable element within the host document. Other compound document specifications may define supplemental SVG focus navigation rules for situations when SVG content is used as a component within a compound document.

User agents should provide a mechanism for a user to escape from a focus ring. When the user activates this mechanism, the user agent should change focus to the user agent, sending the appropriate focusout event to the element currently in focus.

13.13.2 Specifying navigation

Attribute definitions:

nav-next,

nav-prev = "<FuncIRI>" | "auto" | "self"

Specifies the next element (when using 'nav-next') or previous element (when using 'nav-prev') in the focus ring.

The attribute value for 'nav-next' and 'nav-prev' can be one of the following:

<FuncIRI>: Specifies the element that must receive focus when navigation in the next direction (for 'nav-next') or previous direction (for 'nav-prev') is triggered. The specified element must be within the current SVG document fragment.
auto: The lacuna value. Means that the behavior shall be as if the attribute was not specified (navigation must follow the rules specified in Navigation behavior).
self: The focus must stay on the element itself.

Animatable: yes.

nav-up,

nav-up-right,

nav-right,

nav-down-right,

nav-down,

nav-down-left,

nav-left,

nav-up-left = "<FuncIRI>" | "auto" | "self"

Each of these eight attributes specifies an element to receive focus when navigating in a particular direction. For each of the attributes, the direction for which an element is being specified for navigation is suggested by the name of the attribute. The following table lists these directions explicitly:

Attribute name	Direction
'nav-up'	↑ upward
'nav-up-right'	↗ up-and-rightward
'nav-right'	→ rightward
'nav-down-right'	↘ down-and-rightward
'nav-down'	↓ downward
'nav-down-left'	↙ down-and-leftward
'nav-left'	← leftward
'nav-up-left'	↖ up-and-leftward

The value for each of these attributes can be one of the following:

<FuncIRI>: Specifies the element that must receive focus when navigation in the given direction is triggered. The specified element must be within the current SVG document fragment.
auto: The lacuna value. Means that the behavior is left up to the SVG user agent.
self: The focus must stay on the element itself.

Animatable: yes.

Example: navigation.svg

<svg xmlns="http://www.w3.org/2000/svg" 
     xmlns:xlink="http://www.w3.org/1999/xlink" 
     version="1.2" baseProfile="tiny" 
     viewBox="0 0 220 40">

  <title>Media Channel Navigation User Interface</title>
  <desc>An example which illustrates the use of nav-* attributes</desc>

  <!-- List of available channels -->
  <rect x="0" y="0" width="100" height="20" fill="#fb0" stroke="#000" stroke-width="2" />
  <text x="50" y="13" font-size="8" font-family="Arial Black" 
        fill="#fff" text-anchor="middle">Channel 1</text>
  <rect x="0" y="20" width="100" height="20" fill="#fb0" stroke="#000" stroke-width="2" />
  <text x="50" y="33" font-size="8" font-family="Arial Black" 
        fill="#fff" text-anchor="middle">Channel 2</text>
  <rect x="0" y="40" width="100" height="20" fill="#fb0" stroke="#000" stroke-width="2" />
  <text x="50" y="53" font-size="8" font-family="Arial Black" 
        fill="#fff" text-anchor="middle">Channel 3</text>

  <!-- List of programs for channel nb 1 -->
  <g xml:id="Chan1Prog1" focusable="true" nav-left="self" nav-right="url(#Chan1Prog2)" 
     nav-up="self" nav-down="url(#Chan2Prog1)">
    <rect x="100" y="0" width="100" height="20" fill="#fd0" stroke="#000" stroke-width="2">
      <set attributeName="fill" begin="Chan1Prog1.focusin" end="Chan1Prog1.focusout" to="#fa0"/>
    </rect>
    <text x="150" y="13" font-size="8" font-family="Arial Black" 
          fill="#fff" text-anchor="middle">Weather</text>
  </g>
  <g xml:id="Chan1Prog2" focusable="true" nav-left="url(#Chan1Prog1)" nav-right="url(#Chan1Prog3)" 
     nav-up="self" nav-down="auto">
    <rect x="200" y="0" width="120" height="20" fill="#fd0" stroke="#000" stroke-width="2">
      <set attributeName="fill" begin="Chan1Prog2.focusin" end="Chan1Prog2.focusout" to="#fa0"/>
    </rect>
    <text x="260" y="13" font-size="8" font-family="Arial Black" 
          fill="#fff" text-anchor="middle">The news</text>
  </g>
  <g xml:id="Chan1Prog3" focusable="true" nav-left="url(#Chan1Prog2)" nav-right="self" 
     nav-up="self" nav-down="auto" nav-next="self">
    <rect x="320" y="0" width="120" height="20" fill="#fd0" stroke="#000" stroke-width="2">
      <set attributeName="fill" begin="Chan1Prog3.focusin" end="Chan1Prog3.focusout" to="#fa0"/>
    </rect>
    <text x="380" y="13" font-size="8" font-family="Arial Black" 
          fill="#fff" text-anchor="middle">Football</text>
  </g>

  <!-- List of programs for channel nb 2 -->
  <g xml:id="Chan2Prog1" focusable="true" nav-left="self" nav-right="auto" 
     nav-up="url(#Chan1Prog1)" nav-down="auto" nav-prev="url(#Chan1Prog1)" nav-next="auto">
    <rect x="100" y="20" width="150" height="20" fill="#fd0" stroke="#000" stroke-width="2">
      <set attributeName="fill" begin="Chan2Prog1.focusin" end="Chan2Prog1.focusout" to="#fa0"/>
    </rect>
    <text x="175" y="33" font-size="8" font-family="Arial Black" 
          fill="#fff" text-anchor="middle">Long Movie</text>
  </g>
</svg>

This example illustrates how it is possible for an author to control the focus order between several focusable elements displayed on the canvas.

On a device which provides a 2-way navigation system (a TAB mechanism for instance), here are the interesting behaviors:

On a device which provides a 4-way navigation system (i.e. a joystick for instance), here are the interesting behaviors:

13.13.3 Specifying focus highlighting

Automated highlighting upon focus can be specified using the 'focusHighlight' attribute. This hint indicates whether the SVG user agent should highlight an element on focus. The highlighting method is implementation dependent and the SVG user agent should pick a method that works well for varying content. This attribute is available on all graphical and container elements.

13.13.4 Obtaining and listening to focus programmatically

When the user agent gives an element focus it receives a DOMFocusIn event which has the new focused object as the event target and a DOMFocusOut event which has the previously focused object as the event target.

The SVGSVGElement interface has a setFocus method that puts the focus on the requested object. Calling setFocus with an element that is not focusable causes focus to stay on the currently focused object.

SVG user agents which support pointer devices such as a mouse must allow users to put focus onto focusable elements. For example, it should be possible to click on a focusable element in order to give focus.

Empty text fields in SVG theoretically take up no space, but they have a point or zero-width line segment that represents the location of the empty text field. SVG user agents should allow users with pointer devices to put focus into empty text fields by initiating a select action (e.g., a mouse click) at the location of the empty text field.

An author may change the field navigation order from a script by using the setTrait method to change the current value of navigation attributes on a given element (see Example below).

Example: changeNavigationOrder.svg

<?xml version="1.0"?>

<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     xmlns:ev="http://www.w3.org/2001/xml-events">
     
  <desc>An example of how to change the navigation order from script by
  changing nav-* attribute values. In this example, "myRect2" disappears between 10 and 20 sec 
  and is replaced by the "myRectNew" rectangle during this period. Consequently, the navigation order 
  must be changed accordingly during this period and we must re-established initial order after 20s.</desc>

  <rect xml:id="myRect1" x="10" y="20" width="100" height="50" fill="red" focusable="true" nav-right="url(#myRect2)">
        <set begin="focusin" end="focusout" attributeName="fill" to="purple"/>
  </rect>

  <rect xml:id="myRect2" x="120" y="20" width="100" height="50" fill="red" focusable="true" 
        nav-right="url(#myRect3)" nav-left="url(#myRect1)">
        <set begin="focusin" end="focusout" attributeName="fill" to="purple"/>
        <set begin="0"  end="10" attributeName="display" to="inline"/>
        <set begin="10" end="20" attributeName="display" to="none"/>
        <set begin="20"          attributeName="display" to="inline"/>
  </rect>
  <rect xml:id="myRect3" x="230" y="20" width="100" height="50" fill="red" focusable="true" nav-left="url(#myRect2)">
        <set begin="focusin" end="focusout" attributeName="fill" to="purple"/>
  </rect>

  <rect xml:id="myRectNew" x="120" y="20" width="100" height="50" fill="blue" focusable="true" nav-right="url(#myRect3)" 
        nav-left="url(#myRect1)" display="none" >
        <set xml:id="myRectNewFillAnim"    begin="focusin" end="focusout" attributeName="fill"    to="black"/>
        <set xml:id="myRectNewDisplayAnim" begin="10"      end="20"       attributeName="display" to="inline"/>
  </rect>

  <!-- register a listener for myRectNew.beginEvent event -->
  <ev:listener event="beginEvent" observer="myRectNew" handler="#myAnimationHandler" />
  <ev:listener event="endEvent"   observer="myRectNew" handler="#myAnimationHandler" />

  <!-- handler which is called when myRect2 is replaced by myRectNew -->
  <handler xml:id="myAnimationHandler" type="application/ecmascript"><![CDATA[
    var myRect1 = document.getElementById("myRect1");
    var myRect3 = document.getElementById("myRect3");
    
    if (evt.type == "beginEvent" && evt.target.id == "myRectNewDisplayAnim")
    {
        myRect1.setTrait("nav-right", "url(#myRectNew)");
        myRect3.setTrait("nav-left", "url(#myRectNew)");
    }
    else if (evt.type == "endEvent" && evt.target.id == "myRectNewDisplayAnim")
    {
        myRect1.setTrait("nav-right", "url(#myRect2)");
        myRect3.setTrait("nav-left", "url(#myRect2)");
    }
  ]]></handler>

</svg>

Value:	boundingBox \| visiblePainted \| visibleFill \| visibleStroke \| visible \| painted \| fill \| stroke \| all \| none \| inherit
Initial:	visiblePainted
Applies to:	graphics elements
Inherited:	yes
Percentages:	N/A
Media:	visual
Animatable:	yes
Computed value:	Specified value, except inherit

13 Interactivity

Contents

13.1 Introduction

13.2 Complete list of supported events

13.3 User interface events

13.4 Pointer events

13.5 Text events

13.6 Key events

13.7 Event flow

13.8 Event dispatching

13.9 Processing order for user interface events

13.10 The 'pointer-events' property

13.11 Magnification and panning

13.12 Element focus

13.12.1 The 'focusable' attribute

13.13 Navigation

13.13.1 Navigation behavior

13.13.2 Specifying navigation

13.13.3 Specifying focus highlighting

13.13.4 Obtaining and listening to focus programmatically


Before element `"Chan1Prog2"` receives focus		After element `"Chan1Prog2"` receives focus (UA scrolls automatically)