13 Interactivity

13.1 Introduction

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

• User-initiated actions such as a key-press can cause Timed Elements to start or stop, scripts to execute or 'listener' elements to trigger 'handler' elements.
• The user can initiate hyperlinks to new Web pages (see the 'a' element) by actions such as a stylus click on a particular graphics element.
• In many cases, depending on the value of the 'zoomAndPan' attribute on the 'svg' element and on the characteristics of the SVG User Agent, users are able to zoom into and pan around SVG content.

This chapter describes:

• information about events, including under which circumstances events are triggered
• how to indicate whether a given document can be zoomed and panned
• Element focus and navigation.

Related information can be found in other chapters:

• hyperlinks are discussed in Linking
• 'script' and 'handler' elements are discussed in Scripting
• Timed Elements are discussed in Animation and Multimedia chapters.

13.2 Complete list of supported events

The following aspects of SVG are affected by events:

• The SVG uDOM enables a script to register event listeners so that the script can be invoked when a given event occurs.
• The ev:event attribute on the 'handler' element specifies for which event the 'handler' should trigger.
• Timed Elements can be defined to begin or end based on 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.

Notes:

• In order to unify event names with other W3C languages, SVG 1.2 deprecates some of the SVG 1.1 event names. (The term "deprecate" in this case means that user agents which are compatible with both SVG 1.1 and SVG 1.2 must support both the old deprecated event names and the new event names. Content creators who are making content that targets SVG 1.2 should use the new event names, not the deprecated event names.) Here are the specifics:
  • "SVGLoad" event is deprecated in favor of "load"
  • "SVGResize" event is deprecated in favor of "resize"
  • "SVGScroll" event is deprecated in favor of "scroll"
• As per DOM3, the load event does not bubble.

Details on the parameters passed to event listeners for the event types from DOM3 can be found in the DOM3 specification. For other event types, the parameters passed to event listeners 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:

<?xml version="1.0" encoding="UTF-8"?>
<svg width="6cm" height="5cm" viewBox="0 0 600 500" xmlns="http://www.w3.org/2000/svg" version="1.2"
    baseProfile="tiny" xmlns:ev="http://www.w3.org/2001/xml-events">
    <desc>Example: invoke an ECMAScript function from a DOMActivate event </desc>
    <!-- ECMAScript to change the radius -->
    <script type="application/ecmascript">
        <![CDATA[
     function change(evt) {
       var circle = evt.target;
       var currentRadius = circle.getFloatTrait("r");
       if (currentRadius == 100)
         circle.setFloatTrait("r", currentRadius*2);
       else
         circle.setFloatTrait("r", currentRadius*0.5);
     }
   ]]>
    </script>
    <!-- Act on each DOMActivate event -->
    <circle cx="300" cy="225" r="100" fill="red">
        <handler type="application/ecmascript" ev:event="DOMActivate"> change(evt); </handler>
    </circle>
    <text x="300" y="480" font-family="Verdana" font-size="35" text-anchor="middle"> Activate the
        circle to change its size </text>
</svg>
    

For all UI event-related features defined as part of the SVG language via XML Events or animation, the event model corresponds to the event bubbling model described in DOM3 [DOM3Events]. An SVG User Agents is not required to support the event capture model from DOM3.

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. DOM 3 Text Events only requires that a string of Unicode characters is returned, making it independent of the input device used.

13.6 Key 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 (full-size) keyboard.

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 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. If the user agent cannot find a graphics element or SVGElementInstance object to be the target object (e.g., the pointer event occurs over the viewport background), then the user agent must set the target object to be the rootmost svg element.

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 there is no target object, the event is not dispatched.
• Otherwise, if the target object has an appropriate event handler for the given event, the event is dispatched to the target object.
• Otherwise, each ancestor of the target object (starting with its immediate parent) is checked to see if it has an appropriate event handler. If an ancestor is found with an appropriate event handler, the event is dispatched to that ancestor element.
• Otherwise, the event is discarded.

When event bubbling [DOM3Events] is active, 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.8 Processing order for user interface events

The processing order for user interface events shall be as follows:

• Event handlers assigned to the topmost graphics element under the pointer (and the various ancestors of that graphics element via potential event bubbling) receive the event first. If none of the activation event handlers take an explicit action to prevent further processing of the given event, then the event is passed on for:
• (For those user interface events which invoke hyperlinks, such as mouse clicks in some user agents) Link processing. If a hyperlink is invoked in response to a user interface event, the hyperlink typically will disable further activation event processing (e.g., often, the link will define a hyperlink to another Web page). If link processing does not disable further processing of the given event, then the event is passed on for:
• (For those user interface events which can select text, such as mouse clicks and drags on 'text' elements) Text selection processing. When a text selection operation occurs, typically it will disable further processing of the given event; otherwise, the event is passed on for:
• Document-wide event processing, such as user agent facilities to allow zooming and panning of an SVG document fragment.

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.9 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:

• user interface events such as key press.
• hyperlinks (see the 'a' element)

boundingBox

The given element must be a target element for pointer events when the pointer is over the bounding box of the element.

visiblePainted

The given element must only be a target element for pointer events when the 'visibility' property is set to visible and when the pointer is over a "painted" area. The pointer is over a painted area if it is over the interior (i.e., 'fill') of the element and the 'fill' property is set to a value other than none or it is over the perimeter (i.e., 'stroke') of the element and the 'stroke' property is set to a value other than none.

visibleFill

The given element must only be a target element for pointer events when the 'visibility' property is set to visible and when the pointer is over the interior (i.e., 'fill') of the element. The value of the 'fill' property does not effect event processing.

visibleStroke

The given element must only be a target element for pointer events when the 'visibility' property is set to visible and when the pointer is over the perimeter (i.e., 'stroke') of the element. The value of the 'stroke' property does not effect event processing.

visible

The given element must only be a target element for pointer events when the 'visibility' property is set to visible and the pointer is over either the interior (i.e., 'fill') or the perimeter (i.e., 'stroke') of the element. The values of the 'fill' and 'stroke' do not effect event processing.

painted

The given element must only be a target element for pointer events when the pointer is over a "painted" area. The pointer is over a painted area if it is over the interior (i.e., 'fill') of the element and the 'fill' property is set to a value other than 'none' or it is over the perimeter (i.e., 'stroke') of the element and the 'stroke' property is set to a value other than none. The value of the 'visibility' property does not effect event processing.

fill

The given element must only be a target element for pointer events when the pointer is over the interior (i.e., 'fill') of the element. The values of the 'fill' and 'visibility' properties do not effect event processing.

stroke

The given element must only be a target element for pointer events when the pointer is over the perimeter (i.e., 'stroke') of the element. The values of the 'stroke' and 'visibility' properties do not effect event processing.

all

The given element must be a target element for pointer events whenever the pointer is over either the interior (i.e., 'fill') or the perimeter (i.e., 'stroke') of the element. The values of the 'fill', 'stroke' and 'visibility' properties do not effect event processing.

none

The given element must not receive pointer events.

For text elements, hit detection shall be performed on a character cell basis:

• The value visiblePainted means that the text string can receive events anywhere within the character cell if either the 'fill' property is set to a value other than none or the 'stroke' property is set to a value other than none, with the additional requirement that the 'visibility' property is set to visible.
• The values visibleFill, visibleStroke and visible are equivalent and indicate that the text string can receive events anywhere within the character cell if the 'visibility' property is set to visible. The values of the 'fill' and 'stroke' properties do not effect event processing.
• The value painted means that the text string can receive events anywhere within the character cell if either the 'fill' property is set to a value other than none or the 'stroke' property is set to a value other than none. The value of the 'visibility' property does not effect event processing.
• The values fill, stroke and all are equivalent and indicate that the text string can receive events anywhere within the character cell. The values of the 'fill', 'stroke' and 'visibility' properties do not effect event processing.
• The value none indicates that the given text does not receive pointer events.

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:

• The value visiblePainted means that the raster image can receive events anywhere within the bounds of the image if any pixel from the raster image which is under the pointer is not fully transparent, with the additional requirement that the 'visibility' property is set to visible.
• The values visibleFill, visibleStroke and visible are equivalent and indicate that the image can receive events anywhere within the rectangular area for the image if the 'visibility' property is set to visible.
• The value painted means that the raster image can receive events anywhere within the bounds of the image if any pixel from the raster image which is under the pointer is not fully transparent. The value of the 'visibility' property does not effect event processing.
• The values fill, stroke and all are equivalent and indicate that the image can receive events anywhere within the rectangular area for the image. The value of the 'visibility' property does not effect event processing.
• The value none indicates that the image does not receive pointer events.

Note that for raster images, the values of properties 'fill-opacity', 'stroke-opacity', 'fill' and 'stroke' do not effect event processing.

13.10 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.11 Element focus

13.11.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.

All renderable elements are required to be able to accept focus if specified by the author, including container elements (except 'defs'), graphics elements, 'tspan' and 'foreignObject'. A focusable container element may contain focusable descendants.

13.12 Navigation

13.12.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 evaluates to "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:

    <rect xml:id="r1" focusable="true".../>
    <g xml:id="g1" focusable="true">
      <circle xml:id="c1" focusable="true".../>
    </g>

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:

• The SVG User Agent must not navigate to an element which has display='none'. (An element which has display='none' is not focusable.)
• The SVG User Agent must allow navigation to elements which are not visible (i.e. which has a 100% transparency or which is hidden by another element).
• The SVG User Agent must allow navigation to elements which are located outside of the current viewport. In this case it is recommended that the SVG User Agent should change the current viewport so that the focused element becomes visible.

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

• Focusable elements within the content referenced by a 'use' element participate in field navigation operations using the flattened focus model. (Note: If a referenced group contains a focusable element, and that group is referenced by two 'use' elements, then the document will have two separate focusable fields, not just one.)
• If an 'animation' element references an SVG document, then all of the focusable fields defined within the referenced SVG document participate in field navigation operations using the flattened focus model.

Focus navigation shall behave as specified:

1. When the document is loaded the focus is first offered to the SVG User Agent.
2. Once the SVG User Agent releases focus, then focus passes to the entity that first matches the following criteria:
   1. the rootmost svg element if it is focusable,
   2. the element referenced by the 'nav-next' attribute on the rootmost svg element, if the attribute is present,
   3. the first focusable element in the document starting from the rootmost svg element,
   4. the SVG User Agent
3. If the focus is held by an element in the document, then the next element in navigation order shall be the entity that first matches the following criteria:
   1. the element referenced by the 'nav-next' attribute on the focused element,
   2. the next focusable element in document order,
   3. the SVG User Agent
4. If the focus is held by an element in the document, then the previous element in navigation order shall be the entity that first matches the following criteria:
   1. the element referenced by the 'nav-prev' attribute on the focused element,
   2. the previous focusable element in document order,
   3. the SVG User Agent

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.12.2 Specifying navigation

Navigation order can be specified using the attributes defined below.

nav-next

The 'nav-next' attribute specifies the next element in the focus ring.

nav-prev

The 'nav-prev' attribute specifies the previous element in the focus ring.

nav-up

The 'nav-up' attribute specifies the element to be focused if a navigation in the upward direction is triggered.

nav-up-right

The 'nav-up-right' attribute specifies the element to be focused if a navigation in the upward-rightward direction is triggered.

nav-right

The 'nav-right' attribute specifies the element to be focused if a navigation in the rightward direction is triggered.

nav-down-right

The 'nav-down-right' attribute specifies the element to be focused if a navigation in the downward-rightward direction is triggered.

nav-down

The 'nav-down' attribute specifies the element to be focused if a navigation in the downward direction is triggered.

nav-down-left

The 'nav-down-left' attribute specifies the element to be focused if a navigation in the downward-leftward direction is triggered.

nav-left

The 'nav-left' attribute specifies the element to be focused if a navigation in the leftward direction is triggered.

nav-up-left

The 'nav-up-left' attribute specifies the element to be focused if a navigation in the upward-leftward direction is triggered.

<?xml version="1.0"?>

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

• Whenever the focus is located on a program which is at the beginning of the timeline of a given channel, there are 3 options when the user wants to go to the previous focusable item (i.e., the user presses the "Reverse-Tab" key on most desktop computers):
  • option 1: the focus goes up to the first program of the previous channel
  • option 2: the focus goes up to the last program of the previous channel
  • option 3: the focus remains at the same place

  Here, in this example, for channel 2, because there is nav-prev="url(#Chan1Prog1)" attribute in element 'g' with id="Chan2Prog1", option 1 will be applied.

  In order to apply option 2, we could have set nav-prev="url(#Chan1Prog3)" instead.

  In order to apply option 3, we could have set nav-prev="self" instead.

• Whenever the focus is located on a program which is at the end of the timeline of a given channel, there are 2 options when the user wants to go to the next focusable item (i.e., the user presses the "Tab" key on most desktop computers):
  • option 1: the focus goes down to the first program of the next channel
  • option 2: the focus remains at the same place

  Here, in this example, for channel 1, because there is nav-next="self" attribute in element 'g' with id="Chan1Prog3", option 2 will be applied.

  In order to apply option 1, we could have set nav-next="url(#Chan2Prog1)" instead.

• Whenever the focus is located on "Chan2Prog1" container, if the user wants to go to the next focusable element, the concept of a focus ring will apply because of value nav-next="auto". Here, according to the focus ring navigation rules, focus will be offered to the SVG User Agent because there is no more focusable element in the document order.

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

• Whenever the focus is located at the beginning of the timeline of a given channel, when the user wants to go "Left", focus remains on the same element because both element 'g' with id="Chan1Prog1" and element 'g' with id="Chan2Prog1" have nav-left="self".
• Whenever the focus is located on "Chan1Prog1" container, if the user wants to go 'Right', the focus will be put on container element "Chan1Prog2" because of the nav-right="url(#Chan1Prog2)" value. But, because some part of "Chan1Prog2" bounding box is outside of the current viewport, the SVG User Agent should change the current viewport so that the new focused element becomes visible.

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

• On element 'g' with id="Chan2Prog1", there is a value nav-right="auto". This value is the default one for nav-* attributes and therefore the behavior is the same as if no 'nav-right' attribute was defined. This value "auto" means that it's up to the SVG User Agent to choose which focusable element should receive focus when the user wants to go 'right'.

13.12.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.

Example: focusHighlight.svg

<?xml version="1.0"?>

<svg viewBox="0 0 210 80" 
	xmlns="http://www.w3.org/2000/svg"
	xmlns:xlink="http://www.w3.org/1999/xlink"
	version="1.2" baseProfile="tiny">
  
  <desc>An example which illustrates the use of focusHighlight attribute</desc>

	<text x="5" y="10">Do you want to validate transaction ?</text>
	<text x="5" y="25">You may read <a xlink:href="http://www.example.org/pay"
	                     >this</a> and <a xlink:href="http://www.example.org/infos">that</a>
	</text>
	
	<a xml:id="ValidateButton" transform="translate(5,40)" focusHighlight="none" xlink:href="validate.htm">
		<rect x="0" y="0" width="90" height="20" fill="#0f0" stroke="#000" stroke-width="2">
			<set attributeName="fill" begin="ValidateButton.focusin" end="ValidateButton.focusout" to="#0a0"/>
		</rect>
		<text x="45" y="13" font-size="8" font-family="Arial Black"  
		      fill="#000" text-anchor="middle">Validate</text>
	</a>
	<a xml:id="AbortButton" transform="translate(100,40)" focusHighlight="none" xlink:href="abort.htm">
		<rect x="0" y="0" width="90" height="20" fill="#f00" stroke="#000" stroke-width="2">
			<set attributeName="fill" begin="AbortButton.focusin" end="AbortButton.focusout" to="#a00"/>
		</rect>
		<text x="45" y="13" font-size="8" font-family="Arial Black" 
		      fill="#000" text-anchor="middle">Abort</text>
	</a>

</svg>
    

In the above SVG example:

• highlight of the focus on the first two textual links is left up to the SVG User Agent (underline the text, highlight of the bounding box, change color of the text, ...) since the lacuna value is focusHighlight="auto". This text may have been retrieved from a database where there may be no notion of graphical styling or no way to know in advance the kind of focusable elements it contains, therefore the author doesn't handle focus highlight on that part of the document.
• highlight of the focus on the 2 graphical buttons is designed by the author and therefore the SVG User Agent doesn't need to highlight it as well. Therefore, focusHighlight="none" is used to disable the default focus highlight behavior.

13.12.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.

The SVGSVGElement interface has a moveFocus(short motionType) which moves current focus to a different object based on the value of motionType.

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 nav-* attributes on a given element (see Example below).

<?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>