diff --git a/graphics2.html b/graphics2.html index b857c7a..85d7fbc 100644 --- a/graphics2.html +++ b/graphics2.html @@ -1,388 +1,452 @@ - -WAI-ARIA Graphics Module 2 - - - - - - - - + + + + + + - - - -
-

Assistive technologies need semantic information about widgets, structures and behaviors to convey appropriate information to persons with disabilities. This specification defines a [[!WAI-ARIA]] module of roles, states and properties specific to web graphics. These semantics allow an author to convey user interface behaviors and structural information to assistive technologies and to enable semantic navigation, styling and interactive features used by readers. It is expected this will complement [[HTML5]] and [[SVG2]].

-

This document is part of the WAI-ARIA suite described in the WAI-ARIA Overview.

-
-
-

Please record issues on this specification through the Github W3C/aria issue tracker, using the prefix "Graphics" for any issue.

-
-
-
-
-

Introduction

-

WAI-ARIA is a technical specification that defines a common host language semantic accessibility API and framework that enables web browsers to map the accessibility semantics in web content to platform-specific accessibility APIs. This enables web content to be interoperable with platform assistive technologies similar to native platform applications without platform dependencies.

-

This specification is a modular extension of WAI-ARIA designed to support graphics. The goals of this specification include:

- -

For a more detailed explanation of WAI-ARIA please refer to the WAI-ARIA Introduction and how it applies to Rich Internet Application Accessibility.

- -
-

Target Audience

-

This specification defines a module of WAI-ARIA for graphics, including roles, states, properties and values. It impacts several audiences:

- -

Each conformance requirement indicates the audience to which it applies.

- -
- -
-

User Agent Support

-

This module builds on the general User Agent support principles defined in [[!WAI-ARIA]] by also providing the ability for user agents to enhance the general user interface presented to readers.

-
- -
-

Co-Evolution of WAI-ARIA and Host Languages

-

The Graphics WAI-ARIA module follows the model for co-evolution of WAI-ARIA and host languages defined in [[!WAI-ARIA]]. It is intended to augment semantics in supporting languages like [[HTML5]], [[!SVG2]] and EPUB, or to be used as an accessibility enhancement technology in other markup-based languages that do not explicitly include support for ARIA. It clarifies semantics to assistive technologies when authors create new types of objects, via style and script, that are not yet directly supported by the language of the page, because the invention of new types of objects is faster than standardized support for them appears in web languages.

-

It is not appropriate to create objects with style and script when the host language provides a semantic element for that type of objects. While WAI-ARIA can improve the accessibility of these objects, accessibility is best provided by allowing the user agent to handle the object natively. For example, it is not better to use a heading role on a div element than it is to use a native heading element, such as an h1.

-

It is expected that, over time, host languages will evolve to provide semantics for objects that currently can only be declared with this specification. This is natural and desirable, as one goal of WAI-ARIA is to help stimulate the emergence of more semantic and accessible markup. When native semantics for a given feature become available, it is appropriate for authors to use the native feature and stop using this module for that feature. Legacy content may continue to use the Graphics WAI-ARIA module, however, so the need for user agents to support it remains.

-

While specific features of this module may lose importance over time, the general possibility of the Graphics WAI-ARIA module to add semantics to web graphics or open web based standards, is expected to be a persistent need. Host languages may not implement all the semantics this module provides, and various host languages may implement different subsets of the features. New types of objects are continually being developed, and one goal of this specification is to provide a way to make such objects accessible, because authoring practices often advance faster than host language standards. In this way, this module and host languages both evolve together but at different rates.

-

Some host languages exist to create semantics for features other than the user interface. For example, SVG expresses the semantics behind production of graphical objects, not of user interface components that those objects may represent. Host languages such as these might, by design, not provide native semantics that map to this specification's features. In these cases, the Graphics WAI-ARIA module could be adopted as a long-term approach to add semantic information to these host languages.

-
- -
-

Authoring Practices

-
-

Authoring Tools

-

Many of the requirements in the definitions of the WAI-ARIA and Graphics WAI-ARIA roles, states and properties can be checked automatically during the development process, similar to other quality control processes used for validating code. To assist authors who are creating graphics, can compare the semantic structure of Graphics WAI-ARIA roles from the DOM to that defined in this specification and notify the author of errors or simply create templates that enforce that structure.

-
- -
-

Testing Practices and Tools

-

The accessibility of interactive content cannot be confirmed by static checks alone. Developers of interactive content should test for device-independent access to widgets and applications, and should verify accessibility API access to all content and changes during user interaction.

-
-
- -
-

Assistive Technologies

-

Programmatic access to accessibility semantics is essential for assistive technologies. For more information, refer to the Assistive Technologies section in [[!WAI-ARIA]].

-
-
-
-

This specification indicates whether a section is normative or informative. Classifying a section as normative or informative applies to the entire section. A statement "This section is normative" or "This section is informative" applies to all sub-sections of that section.

-

Normative sections provide requirements that authors, user agents and assistive technologies MUST follow for an implementation to conform to this specification.

-

Informative sections provide information useful to understanding the specification. Such sections may contain examples of recommended practice, but it is not required to follow such recommendations in order to conform to this specification.

-
-
-

Important Terms

-
-
-
-

Graphics Roles

-

- This section defines additions to the - WAI-ARIA - role taxonomy - and describes the characteristics and properties of all roles. - See ARIA Roles for descriptions - of the fields provided by this module. -

-

Authors are given the ability to influence what is presented to assistive technologies and to influence navigation through - the use of roles and properties. With graphics, there are many cases where presenting and navigating every element will make the - graphic harder to understand and use. Authors may mark elements for non-visual exclusion by assigning the role none. Graphics also - have situations where the author intent is ambiguous and the use of the property aria-type should be used to clarify the situation.

-

If an author does not want a user agent to non-visually present an element and does not want the - element included in navigaion then the element should be given a role of none. For example, in the case - an author does not want a chart's axis minor tick marks (tick lines without labels between tick marks with labels) - presented to assistive technologies since the minor tick marks would add significant noise without increasing comprehension, then the - author should assign the minor tick marks the role of none.

- -

User agents are expected to use the aria-gtype property - for differentiating between graph features. Two elements with the - same role and the same semanatic parent and both elements having either no aria-gtype or the same aria-gtype - are defined as being part of the same feature. - Two elements with a the same role and the same semanatic parent but differing aria-gtype - are defined as being two separate features. + } + + + +

+

+ Assistive technologies need semantic information about widgets, structures and behaviors to convey appropriate information to persons with disabilities. This specification defines a + [[!WAI-ARIA]] module of roles, states and properties specific to web graphics. These semantics allow an author to convey user + interface behaviors and structural information to assistive technologies and to enable semantic navigation, styling and interactive features used by readers. It is expected this will + complement [[HTML5]] and [[SVG2]]. +

+

+ This document is part of the WAI-ARIA suite described in the + WAI-ARIA Overview. +

+
+
+

Please record issues on this specification through the Github W3C/aria issue tracker, using the prefix "Graphics" for any issue.

+
+
+
+

Introduction

+

+ WAI-ARIA is a technical specification that defines a common host language semantic accessibility API and framework that enables web + browsers to map the accessibility semantics in web content to platform-specific accessibility APIs. This enables web content to be interoperable with platform assistive technologies similar to + native platform applications without platform dependencies. +

+

This specification is a modular extension of WAI-ARIA designed to support graphics. The goals of this specification include:

+ +

+ For a more detailed explanation of WAI-ARIA please refer to the + WAI-ARIA Introduction and how it applies to Rich Internet Application Accessibility. +

+ +
+

Target Audience

+

+ This specification defines a module of WAI-ARIA for graphics, including roles, states, + properties and values. It impacts several audiences: +

+
    +
  • + User agents that process content containing WAI-ARIA and graphics (SVG) + WAI-ARIA features; +
    • +
  • Assistive technologies that provide specialized reading experiences to users with disabilities;
    • +
  • Authors of web graphics (SVG);
    • +
  • Authoring tools that help authors create conforming graphics; and
    • +
  • + Conformance checkers, that verify appropriate use of WAI-ARIA and this Graphics + WAI-ARIA module. +
    • +
+

Each conformance requirement indicates the audience to which it applies.

+ +
+ +
+

User Agent Support

+

+ This module builds on the general User Agent support principles defined in [[!WAI-ARIA]] by also providing the ability for user + agents to enhance the general user interface presented to readers. +

+
+ +
+

Co-Evolution of WAI-ARIA and Host Languages

+

+ The Graphics WAI-ARIA module follows the model for + co-evolution of WAI-ARIA and host languages defined in [[!WAI-ARIA]]. + It is intended to augment semantics in supporting languages like [[HTML5]], [[!SVG2]] and EPUB, or to be used as an accessibility enhancement technology in other markup-based languages that + do not explicitly include support for ARIA. It clarifies semantics to assistive technologies when authors create new types of objects, via style and script, that are not yet directly + supported by the language of the page, because the invention of new types of objects is faster than standardized support for them appears in web languages. +

+

+ It is not appropriate to create objects with style and script when the host language provides a semantic element for that type of objects. While + WAI-ARIA can improve the accessibility of these objects, accessibility is best provided by allowing the user agent to handle the + object natively. For example, it is not better to use a heading role on a div element than it is to use a native heading element, such as an h1. +

+

+ It is expected that, over time, host languages will evolve to provide semantics for objects that currently can only be declared with this specification. This is natural and desirable, as one + goal of WAI-ARIA is to help stimulate the emergence of more semantic and accessible markup. When native semantics for a given + feature become available, it is appropriate for authors to use the native feature and stop using this module for that feature. Legacy content may continue to use the Graphics + WAI-ARIA module, however, so the need for user agents to support it remains.

- - -
-

Definition of Roles

-

- Below is an alphabetical list of the - WAI-ARIA - roles defined in this specification. - They would normally be used in combination with other roles - defined in [[WAI-ARIA]] - to annotate graphics within documents and rich internet applications. +

+ While specific features of this module may lose importance over time, the general possibility of the Graphics WAI-ARIA module to + add semantics to web graphics or open web based standards, is expected to be a persistent need. Host languages may not implement all the semantics this module provides, and various host + languages may implement different subsets of the features. New types of objects are continually being developed, and one goal of this specification is to provide a way to make such objects + accessible, because authoring practices often advance faster than host language standards. In this way, this module and host languages both evolve together but at different rates. +

+

+ Some host languages exist to create semantics for features other than the user interface. For example, SVG expresses the semantics behind production of graphical objects, not of user + interface components that those objects may represent. Host languages such as these might, by design, not provide native semantics that map to this specification's features. In these cases, + the Graphics WAI-ARIA module could be adopted as a long-term approach to add semantic information to these host languages. +

+
+ +
+

Authoring Practices

+
+

Authoring Tools

+

+ Many of the requirements in the definitions of the WAI-ARIA and Graphics + WAI-ARIA roles, states and properties can be checked + automatically during the development process, similar to other quality control processes used for validating code. To assist authors who are creating graphics, can compare the semantic + structure of Graphics WAI-ARIA roles from the DOM to that defined in this + specification and notify the author of errors or simply create templates that enforce that structure. +

+
+ +
+

Testing Practices and Tools

+

+ The accessibility of interactive content cannot be confirmed by static checks alone. Developers of interactive content should test for device-independent access to + widgets and applications, and should verify accessibility API access to all content and changes during user + interaction. +

+
+
+ +
+

Assistive Technologies

+

+ Programmatic access to accessibility semantics is essential for assistive technologies. For more information, refer to the + Assistive Technologies section in [[!WAI-ARIA]]. +

+
+
+
+

+ This specification indicates whether a section is normative or informative. Classifying a section as normative or informative applies to the entire section. A statement "This + section is normative" or "This section is informative" applies to all sub-sections of that section.

- -

Placeholder for compact list of roles

-
- -
- graphics-annotation -
-

A type of guide object, usually a comment, explaination or note.

-
- 
+      
Normative sections provide requirements that authors, user agents and assistive technologies MUST follow for an implementation to conform to this specification.

+      

+        Informative sections provide information useful to understanding the specification. Such sections may contain examples of recommended practice, but it is not required to follow such
+        recommendations in order to conform to this specification.
+      

+
+
+

Important Terms

+
+
+
+

Graphics Roles

+

+ This section defines additions to the + WAI-ARIA + role taxonomy and describes the characteristics and properties of all roles. See ARIA Roles for descriptions of the fields + provided by this module. +

+

+ Authors are given the ability to influence what is presented to assistive technologies and to influence navigation through the use of roles and properties. With graphics, there are many cases + where presenting and navigating every element will make the graphic harder to understand and use. Authors may mark elements for non-visual exclusion by assigning the role none. + Graphics also have situations where the author intent is ambiguous and the use of the property aria-type should be used to clarify the situation. +

+

+ If an author does not want a user agent to non-visually present an element and does not want the element included in navigaion then the element should be given a role of none. For + example, in the case an author does not want a chart's axis minor tick marks (tick lines without labels between tick marks with labels) presented to assistive technologies since the minor tick + marks would add significant noise without increasing comprehension, then the author should assign the minor tick marks the role of none. +

+ +

+ User agents are expected to use the aria-gtype property for differentiating between graph features. Two elements with the same role and the same semanatic parent and both elements + having either no aria-gtype or the same aria-gtype are defined as being part of the same feature. Two elements with a the same role and the same semanatic parent but + differing aria-gtype + are defined as being two separate features. +

+ +
+

Definition of Roles

+

+ Below is an alphabetical list of the + WAI-ARIA + roles defined in this specification. They would normally be used in combination with other roles defined in [[WAI-ARIA]] to annotate graphics within documents and rich + internet applications. +

+ +

Placeholder for compact list of roles

+
+ +
+ graphics-annotation +
+

A type of guide object, usually a comment, explaination or note.

+
+ 
   <g role="graphics-annotation" font-family="Arial" text-anchor="middle" font-size="12" >   
     <text x="320" y="12.56" role="graphics-label">Sample map with two-level color coding.</text>   
     <text x="320" y="26.56" role="graphics-label">The basic hue is set by the region, a categorical variable.</text>    
     <text x="320" y="40.56" role="graphics-label">The color is then modified by a numeric variable. </text>    
     <text x="320" y="54.56" role="graphics-label">See the color aesthetics of the element for the general technique. </text>   
   </g>   
-
- - - - - Sample map with two-level color coding. - The basic hue is set by the region, a categorical - -variable. - The color is then modified by a numeric variable. - See the color aesthetics of the element for the general technique. - - - - -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Characteristics:
CharacteristicValue
Is Abstract:
Superclass Role:graphics-guide
Subclass Roles:
Base Concept:
Related Concepts: Text annotation
Required Context Role:
Required Owned Elements:
Required States and Properties:
Supported States and Properties:aria-gtype
Inherited States and Properties:
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:
Inherits Presentational:
Implicit Value for Role:
-
-
- -
- graphics-axis -
-

A scale often used with charts to show the scale of a dimension (variable).

-

When a graph contains more than one axis, an author should distinguish between the - axes by using - the aria-gtype property. User agents will be expected to use the aria-gtype property - when presenting information to a user and for differentiating between graph features. Two elements with a - graphics-axis role with the same semanatic parent and no aria-gtype or the same aria-gtype are defined as being part of the same axis. - Two elements with a graphics-axis role with the same semanatic parent but differing aria-gtype - are defined as being two separate axes. -

-

Differentiating between axes using the aria-gtype can help users understand whether the axis is - the x, y or z axis and help them understand which variable/data column is associated with the axis. Differentiating between - axes using aria-gtype can also affect how keyboard users navigate through the axes. This level of control is - provided to authors so they can convey and control how user agents perceive axes given the author may need to present mulitple y - axis on opposite sides of the chart (ie left axis in inches, right axis in cm), clustered sets of axes, 3 or more dimension axes and aligned - axes shared by two charts in the same visualization.

- - 
+
+ + + + + Sample map with two-level color coding. + The basic hue is set by the region, a categorical variable. + The color is then modified by a numeric variable. + See the color aesthetics of the element for the general technique. + + + +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Characteristics: +
CharacteristicValue
Is Abstract:
Superclass Role:graphics-guide
Subclass Roles:
Base Concept:
Related Concepts:Text annotation
Required Context Role:
Required Owned Elements:
Required States and Properties:
Supported States and Properties:aria-gtype
Inherited States and Properties:
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:
Inherits Presentational:
Implicit Value for Role:
+ +
+ +
+ graphics-axis +
+

A scale often used with charts to show the scale of a dimension (variable).

+

+ When a graph contains more than one axis, an author should distinguish between the axes by using the aria-gtype property. User agents will be expected to use the aria-gtype + property when presenting information to a user and for differentiating between graph features. Two elements with a graphics-axis role with the same semanatic parent and no + aria-gtype or the same aria-gtype are defined as being part of the same axis. Two elements with a graphics-axis role with the same semanatic parent but + differing aria-gtype + are defined as being two separate axes. +

+

+ Differentiating between axes using the aria-gtype can help users understand whether the axis is the x, y or z axis and help them understand which variable/data column is + associated with the axis. Differentiating between axes using aria-gtype can also affect how keyboard users navigate through the axes. This level of control is provided to + authors so they can convey and control how user agents perceive axes given the author may need to present mulitple y axis on opposite sides of the chart (ie left axis in inches, right + axis in cm), clustered sets of axes, 3 or more dimension axes and aligned axes shared by two charts in the same visualization. +

+ + 
 <g transform="translate(57 29)" role="graphics-axis" aria-gtype="y" aria-labelledby="yt" font-family="Arial">
   <path fill="none" d="m0 0v353"/>
   <text id="yt" x="176" y="-38" text-anchor="middle" font-weight="bold" transform="matrix(0-1 1 0 0 353)" >Sales
@@ -416,202 +480,212 @@ 
Definition of Roles

     </g>
   </g>
 </g>
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Characteristics:
CharacteristicValue
Is Abstract:
Superclass Role:graphics-scale
Subclass Roles:
Base Concept:Chart axes
Related Concepts:
Required Context Role:
Required Owned Elements:
Required States and Properties:
Supported States and Properties: -
  • aria-categories
  • aria-gtype
  • aria-valuemin
  • aria-valuemax
-
Inherited States and Properties:
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:
Inherits Presentational:
Implicit Value for Role:
- -
-
- -
- graphics-axistick -
-

A visible axis tick label.

- - 
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Characteristics: +
CharacteristicValue
Is Abstract:
Superclass Role:graphics-scale
Subclass Roles:
Base Concept:Chart axes
Related Concepts:
Required Context Role:
Required Owned Elements:
Required States and Properties:
Supported States and Properties: +
    +
  • aria-categories
    • +
  • aria-gtype
    • +
  • aria-valuemin
    • +
  • aria-valuemax
    • +
+
Inherited States and Properties:
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:
Inherits Presentational:
Implicit Value for Role:
+
+
+ +
+ graphics-axistick +
+

A visible axis tick label.

+ + 
 
       <text x="-7.667" y="215.86"  role="graphics-axistick">200</text>
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Characteristics:
CharacteristicValue
Is Abstract:
Superclass Role:graphics-axis
Subclass Roles:
Base Concept:Chart axes
Related Concepts:
Required Context Role:
Required Owned Elements:
Required States and Properties:
Supported States and Properties: -
  • aria-posinset
  • aria-setsize
-
Inherited States and Properties:
Name From:content
Accessible Name Required:False
Inherits Name Required:
Children Presentational: True
Inherits Presentational:
Implicit Value for Role:
- -
-
- -
- graphics-datagroup -
-

A semantic group for data. Group elements that do not have semantic meaning, should use a role of none.

-

For example, the group containing the graphics-dataitems in a scatterplot - represents the data feature of the chart and should have the role graphics-datagroup.

-

For example, in a stacked bar chart, the group containing all the stacks should have a role of graphics-datagroup - since the group represents the data feature of the chart. - Each group containing a stack of bars should have a role of graphics-datagroup as they represent a semantic object which can contain - data related information like the sum for the stack.

-

For example, in a pie chart the group containing all the pie wedges should have the role graphics-datagroup as it represents the data feature of the chart. However, - if the group containing all the pie wedges, has two child groups that are only there for style inheirtance, for instance to convey text anchor position to their - children, - then the two child groups are not semantic groups and should have a role of none. -

- 
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Characteristics: +
CharacteristicValue
Is Abstract:
Superclass Role:graphics-axis
Subclass Roles:
Base Concept:Chart axes
Related Concepts:
Required Context Role:
Required Owned Elements:
Required States and Properties:
Supported States and Properties: +
    +
  • aria-posinset
    • +
  • aria-setsize
    • +
+
Inherited States and Properties:
Name From:content
Accessible Name Required:False
Inherits Name Required:
Children Presentational:True
Inherits Presentational:
Implicit Value for Role:
+
+
+ +
+ graphics-datagroup +
+

A semantic group for data. Group elements that do not have semantic meaning, should use a role of none.

+

+ For example, the group containing the graphics-dataitems in a scatterplot represents the data feature of the chart and should have the role graphics-datagroup. +

+

+ For example, in a stacked bar chart, the group containing all the stacks should have a role of graphics-datagroup since the group represents the data feature of the chart. + Each group containing a stack of bars should have a role of graphics-datagroup as they represent a semantic object which can contain data related information like the sum + for the stack. +

+

+ For example, in a pie chart the group containing all the pie wedges should have the role graphics-datagroup as it represents the data feature of the chart. However, if the + group containing all the pie wedges, has two child groups that are only there for style inheirtance, for instance to convey text anchor position to their children, then the two child + groups are not semantic groups and should have a role of none. +

+ 
 <g role="graphics-datagroup">  
   <path d="m72.5 50.936h9v26.07h-9z" aria-label="270,000 shares traded on 7/28/80" role="graphics-dataitem" 
     aria-setsize='4' aria-posinset='1' >  
@@ -630,318 +704,319 @@ 
Definition of Roles

     <title>630,000 shares traded on 7/31/80</title>
   </path>  
 </g> 
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Characteristics:
CharacteristicValue
Is Abstract:False
Superclass Role:group
Subclass Roles:
Base Concept:
Related Concepts:graphics-dataitem
Required Context Role:
Required Owned Elements:
Required States and Properties:
Supported States and Properties: -
  • aria-gtype
  • aria-posinset
  • aria-setsize
-
Inherited States and Properties:
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:
Inherits Presentational:
Implicit Value for Role:
-
-
- -
- graphics-dataitem -
-

An object that represents a single data row or a single data entity. A graphics-dataitem may be further split into child components if needed. - For example, a graphics-dataitem for a box and whisker plot may contain the components of the box and whisker (fence, box, median) and each of the components would - be a graphics-dataitem. A set of graphics-dataitem may be ordered. If ordered, aria-posinset may be used to convey order.

-

The role graphics-dataitem is usually associated with charts, graphs, infographics and data visualizations. - Other domains like technical drawings may prefer using the role graphics-symbol.

- - 
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Characteristics: +
CharacteristicValue
Is Abstract:False
Superclass Role:group
Subclass Roles:
Base Concept:
Related Concepts:graphics-dataitem
Required Context Role:
Required Owned Elements:
Required States and Properties:
Supported States and Properties: +
    +
  • aria-gtype
    • +
  • aria-posinset
    • +
  • aria-setsize
    • +
+
Inherited States and Properties:
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:
Inherits Presentational:
Implicit Value for Role:
+
+
+ +
+ graphics-dataitem +
+

+ An object that represents a single data row or a single data entity. A graphics-dataitem may be further split into child components if needed. For example, a + graphics-dataitem for a box and whisker plot may contain the components of the box and whisker (fence, box, median) and each of the components would be a + graphics-dataitem. A set of graphics-dataitem may be ordered. If ordered, aria-posinset may be used to convey order. +

+

+ The role graphics-dataitem is usually associated with charts, graphs, infographics and data visualizations. Other domains like technical drawings may prefer using the role + graphics-symbol. +

+ + 
   <path d="m188 15.01h9v61.995h-9z" aria-label="630,000 shares traded on 7/31/80"  role="graphics-dataitem">    
     <title>630,000 shares traded on 7/31/80</title>
   </path>  
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Characteristics:
CharacteristicValue
Is Abstract:False
Superclass Role:graphics-object
Subclass Roles:
Base Concept:
Related Concepts:
    -
  • graphics-datagroup
    • -
  • graphics-symbol
    • -
Required Context Role:
Required Owned Elements:
Required States and Properties:
Supported States and Properties: -
  • aria-gtype
  • aria-posinset
  • aria-setsize
-
Inherited States and Properties:
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:
Inherits Presentational:
Implicit Value for Role:
-
-
- -
- graphics-dimensionline -
-

A line that defines the length of an object.

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Characteristics:
CharacteristicValue
Is Abstract:False
Superclass Role:graphics-scale
Subclass Roles:
Base Concept:
Related Concepts:dimension line
Required Context Role:
Required Owned Elements:
Required States and Properties:
Supported States and Properties: - aria-gtype -
Inherited States and Properties:
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:
Inherits Presentational:
Implicit Value for Role:
-
-
- -
- graphics-document -
-

- A graphics document contains complex content - that a user should be able to explore. - Similar to document, - the graphical document may contain interactive widgets, - but is not itself interactive. - User agents may intercept user input - for the purposes of navigation. - A graphics document is distinct from other documents - in that the visual layout of the content has semantic meaning. - Navigation methods may take this into consideration. -

-

- Accessibility technologies that re-format a document - should avoid altering the layout of a graphical document. - For this reason, authors should limit the graphical document role - to regions for which layout has semantic meaning. - A collection of distinct graphics that can be re-arranged - without losing meaning - could instead be described as a graphics-figure - or a group. -

-

- Future specifications are expected to define - sub-classes of this role - for particular types of graphical documents, - such as charts or maps. -

-

- The editors have not finalized the name for this role. -

-

- To support user agents and assistive technologies - based on the ARIA 1.0 specification, - authors may wish to include the document role - as a fallback value, - in the form role="graphics-document document". -

- 
+          -->
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Characteristics: +
CharacteristicValue
Is Abstract:False
Superclass Role:graphics-scale
Subclass Roles:
Base Concept:
Related Concepts:dimension line
Required Context Role:
Required Owned Elements:
Required States and Properties:
Supported States and Properties: + aria-gtype +
Inherited States and Properties:
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:
Inherits Presentational:
Implicit Value for Role:
+
+
+ +
+ graphics-document +
+

+ A graphics document contains complex content that a user should be able to explore. Similar to document, the graphical document may contain interactive widgets, but is not + itself interactive. User agents may intercept user input for the purposes of navigation. A graphics document is distinct from other documents in that the visual layout of the content has + semantic meaning. Navigation methods may take this into consideration. +

+ +

+

+ Accessibility technologies that re-format a document should avoid altering the layout of a graphical document. For this reason, authors should limit the graphical document role to + regions for which layout has semantic meaning. A collection of distinct graphics that can be re-arranged without losing meaning could instead be described as a + graphics-figure or a group. +

+

Future specifications are expected to define sub-classes of this role for particular types of graphical documents, such as charts or maps.

+

The editors have not finalized the name for this role.

+

+ To support user agents and assistive technologies based on the ARIA 1.0 specification, authors may wish to include the document role as a fallback value, in the form + role="graphics-document document". +

+ 
 <!-- An SVG diagram of an electrical circuit -->
 <svg xmlns="http://www.w3.org/2000/svg" 
      width="400" height="200" viewBox="0 0 200 100"
@@ -972,125 +1047,109 @@ 
Definition of Roles
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Characteristics:
CharacteristicValue
Is Abstract: 
Superclass Role:structure
Subclass Roles: 
Base Concept: 
Related Concepts:
Required Context Role: 
Required Owned Elements:
Required States and Properties: 
Supported States and Properties: 
Inherited States and Properties: 
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:False
Inherits Presentational: 
Implicit Value for Role: 
-
-
- -
- graphics-figure -
-

- A distinct perceivable section of the page, - that contributes essential meaning to the main page content, - but is not part of a continuous stream of surrounding text. - A graphics-figure can be shifted within the layout of the document - without disruption, - but it cannot be removed without losing meaning. -

-

- A figure often has a visible caption. - It may be referenced from the surrounding text - using a hyperlink or a numbered label. - Figures will often contain graphical content. - However, other content types - with a similar position in the document structure, - such as labelled code samples or audio elements, - would also be figures. - Figures may be nested, - if the nested figures are also likely - to be referenced as discrete units within the page. -

-

- The semantics of this role are intended to mirror - the native semantics of the - figure - element in [[HTML5]]. - It is expected that future versions of HTML - will make this the default semantic role for that element. -

-

- To support user agents and assistive technologies - based on the ARIA 1.0 specification, - authors may wish to include the region role - as a fallback value, - in the form role="graphics-figure region". -

- 
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Characteristics: +
CharacteristicValue
Is Abstract: 
Superclass Role:structure
Subclass Roles: 
Base Concept: 
Related Concepts:
Required Context Role: 
Required Owned Elements:
Required States and Properties: 
Supported States and Properties: 
Inherited States and Properties: 
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:False
Inherits Presentational: 
Implicit Value for Role: 
+
+
+ +
+ graphics-figure +
+

+ A distinct perceivable section of the page, that contributes essential meaning to the main page content, but is not part of a continuous stream of surrounding text. A + graphics-figure can be shifted within the layout of the document without disruption, but it cannot be removed without losing meaning. +

+

+ A figure often has a visible caption. It may be referenced from the surrounding text using a hyperlink or a numbered label. Figures will often contain graphical content. However, other + content types with a similar position in the document structure, such as labelled code samples or audio elements, would also be figures. Figures may be nested, if the nested figures are + also likely to be referenced as discrete units within the page. +

+

+ The semantics of this role are intended to mirror the native semantics of the + figure + element in [[HTML5]]. It is expected that future versions of HTML will make this the default semantic role for that element. +

+

+ To support user agents and assistive technologies based on the ARIA 1.0 specification, authors may wish to include the region role as a fallback value, in the form + role="graphics-figure region". +

+ 
 <!-- Within an HTML 5 document -->
 <p><a href="#fig1">Figure 1</a> outlines the basic shape 
     elements available in SVG.  As shown in 1(d), a rectangle element 
@@ -1119,565 +1178,568 @@ 
Definition of Roles
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Characteristics:
CharacteristicValue
Is Abstract: 
Superclass Role:region
Subclass Roles: 
Base Concept: - HTML figure
Related Concepts:
Required Context Role: 
Required Owned Elements:
Required States and Properties: 
Supported States and Properties: 
Inherited States and Properties: 
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:False
Inherits Presentational: 
Implicit Value for Role: 
-
-
- -
- graphics-edge -
-

A edge (connector) connects two data items, and may have a from/to relationship. - A edge may form a loop, that is the from and to may be the same item. graphics-edge - is the default role for the connector element.

-

- This role won't appear in the final spec and is temporarily here for completeness during discussions. This role is tied to - the connector element, which won't make it into SVG 2. -

- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Characteristics:
CharacteristicValue
Is Abstract:False
Superclass Role:graphics-dataitem
Subclass Roles:
Base Concept:SVG Connector
Related Concepts:
Required Context Role:
Required Owned Elements:
Required States and Properties:
Supported States and Properties: - aria-gtype -
Inherited States and Properties:
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:
Inherits Presentational:
Implicit Value for Role:
-
-
- - -
- graphics-graticule -
-

A network of lines representing the earth's parallels of latitude and meridians of longitude.

- +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Characteristics: +
CharacteristicValue
Is Abstract:False
Superclass Role:graphics-dataitem
Subclass Roles:
Base Concept:SVG Connector
Related Concepts:
Required Context Role:
Required Owned Elements:
Required States and Properties:
Supported States and Properties: + aria-gtype +
Inherited States and Properties:
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:
Inherits Presentational:
Implicit Value for Role:
+
+
+ +
+ graphics-graticule +
+

A network of lines representing the earth's parallels of latitude and meridians of longitude.

+ -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Characteristics:
CharacteristicValue
Is Abstract:False
Superclass Role:graphics-guide
Subclass Roles:
Base Concept:
Related Concepts:
Required Context Role:
Required Owned Elements:
Required States and Properties:
Supported States and Properties: - aria-gtype -
Inherited States and Properties:
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:
Inherits Presentational:
Implicit Value for Role:
-
-
- - -
- graphics-grid -
-

A network of lines of constant value, usually associated with a value on an axis.

-
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Characteristics: +
CharacteristicValue
Is Abstract:False
Superclass Role:graphics-guide
Subclass Roles:
Base Concept:
Related Concepts:
Required Context Role:
Required Owned Elements:
Required States and Properties:
Supported States and Properties: + aria-gtype +
Inherited States and Properties:
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:
Inherits Presentational:
Implicit Value for Role:
+
+
+ +
+ graphics-grid +
+

A network of lines of constant value, usually associated with a value on an axis.

+ -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Characteristics:
CharacteristicValue
Is Abstract:False
Superclass Role:graphics-guide
Subclass Roles:
Base Concept:
Related Concepts:
Required Context Role:
Required Owned Elements:
Required States and Properties:
Supported States and Properties: - aria-gtype -
Inherited States and Properties:
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:
Inherits Presentational:
Implicit Value for Role:
-
-
- graphics-guide -
-

A guide object used to help interpret the graphic.

-

Even though there are several subclasses of graphics-guide, - graphics-guide is not an abstract role as there are situations where a subclass doesn't - meet the authors need. When graphics-guide is used - the aria-roledescription property - can be used to name the guide type - separately from the name and description - for the particular instance of the guide. -

+ -->
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Characteristics: +
CharacteristicValue
Is Abstract:False
Superclass Role:graphics-guide
Subclass Roles:
Base Concept:
Related Concepts:
Required Context Role:
Required Owned Elements:
Required States and Properties:
Supported States and Properties: + aria-gtype +
Inherited States and Properties:
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:
Inherits Presentational:
Implicit Value for Role:
+
+
+ graphics-guide +
+

A guide object used to help interpret the graphic.

+

+ Even though there are several subclasses of graphics-guide, graphics-guide is not an abstract role as there are situations where a subclass doesn't meet the + authors need. When graphics-guide is used the aria-roledescription property can be used to name the guide type separately from the name and description for the + particular instance of the guide. +

-

- The preceeding paragraph is dependent on - aria-roledescription being incorporated - into the ARIA 1.1 specification. -

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Characteristics:
CharacteristicValue
Is Abstract:False
Superclass Role:graphics-object
Subclass Roles:
Base Concept:
Related Concepts:
Required Context Role:
Required Owned Elements:
Required States and Properties:
Supported States and Properties: - aria-gtype -
Inherited States and Properties:
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:
Inherits Presentational:
Implicit Value for Role:
-
-
- -
- graphics-label -
-

A visible label.

-

If the author does not want the user to be able to navigate to the label, they should have - labeled object's aria-labelledby property reference the label and give the label a role of none - 

+            
The preceeding paragraph is dependent on aria-roledescription being incorporated into the ARIA 1.1 specification.

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Characteristics: +
CharacteristicValue
Is Abstract:False
Superclass Role:graphics-object
Subclass Roles:
Base Concept:
Related Concepts:
Required Context Role:
Required Owned Elements:
Required States and Properties:
Supported States and Properties: + aria-gtype +
Inherited States and Properties:
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:
Inherits Presentational:
Implicit Value for Role:
+
+
+ +
+ graphics-label +
+

A visible label.

+

+ If the author does not want the user to be able to navigate to the label, they should have labeled object's aria-labelledby property reference the label and give the label a + role of none +

+ + 
       <text x="-7.667" y="215.86"  role="graphics-label">200</text>
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Characteristics:
CharacteristicValue
Is Abstract:False
Superclass Role:graphics-object
Subclass Roles:
Base Concept:
Related Concepts:
Required Context Role:
Required Owned Elements:
Required States and Properties:
Supported States and Properties: - aria-gtype -
Inherited States and Properties:
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:True
Inherits Presentational:
Implicit Value for Role:
- -
-
- -
- graphics-legend -
-

A scale for data representation, commonly used on charts, maps, instructional drawings and the like. Legends may show any chart aesthetic (color, size, symbol, size, etc).

-
- 
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Characteristics: +
CharacteristicValue
Is Abstract:False
Superclass Role:graphics-object
Subclass Roles:
Base Concept:
Related Concepts:
Required Context Role:
Required Owned Elements:
Required States and Properties:
Supported States and Properties: + aria-gtype +
Inherited States and Properties:
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:True
Inherits Presentational:
Implicit Value for Role:
+
+
+ +
+ graphics-legend +
+

A scale for data representation, commonly used on charts, maps, instructional drawings and the like. Legends may show any chart aesthetic (color, size, symbol, size, etc).

+
+ 
  <g transform="translate(100)" role="graphics-legend" font-size="12" font-family="Arial,SanSerif" fill="transparent">  
    <path stroke-width="1" d="m0 0h40v144h-40z"/>  
    <path d="m16.5 1.5h7v14h-7z"/>   
@@ -1706,142 +1768,131 @@ 
Definition of Roles

    </g>  
  </g>
   
-
- - - - - - brand - - - - - - 1 - - - - - - - 2 - - - - - - - 3 - - - - -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Characteristics:
CharacteristicValue
Is Abstract:False
Superclass Role:graphics-scale
Subclass Roles:
Base Concept:
Related Concepts:
Required Context Role:
Required Owned Elements:
Required States and Properties:
Supported States and Properties: - aria-gtype -
Inherited States and Properties:
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:
Inherits Presentational:
Implicit Value for Role:
-
-
- -
- graphics-object -
-

- A section of a graphical document - that represents a cohesive item or object - with component parts the user may wish to explore. - It is in contrast to a group of distinct related objects, - or an indivisible img or graphics-symbol component. -

- -

- The editors have not finalized the name for this role. -

-

- To support user agents and assistive technologies - based on the ARIA 1.0 specification, - authors may wish to include the group role - as a fallback value, - in the form role="graphics-object group". -

- 
+
+ + + + + brand + + + + + 1 + + + + + + 2 + + + + + + 3 + + + +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Characteristics: +
CharacteristicValue
Is Abstract:False
Superclass Role:graphics-scale
Subclass Roles:
Base Concept:
Related Concepts:
Required Context Role:
Required Owned Elements:
Required States and Properties:
Supported States and Properties: + aria-gtype +
Inherited States and Properties:
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:
Inherits Presentational:
Implicit Value for Role:
+
+
+ +
+ graphics-object +
+

+ A section of a graphical document that represents a cohesive item or object with component parts the user may wish to explore. It is in contrast to a group of distinct + related objects, or an indivisible img or graphics-symbol component. +

+ +

The editors have not finalized the name for this role.

+

+ To support user agents and assistive technologies based on the ARIA 1.0 specification, authors may wish to include the group role as a fallback value, in the form + role="graphics-object group". +

+ 
 <g role="graphics-object group"
    aria-labelledby="house-label"
    transform="translate(100,325)">
@@ -1918,233 +1969,213 @@ 
Definition of Roles
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Characteristics:
CharacteristicValue
Is Abstract: 
Superclass Role:section
Subclass Roles: 
Base Concept: 
Related Concepts: -
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    + Characteristics: +
    CharacteristicValue
    Is Abstract: 
    Superclass Role:section
    Subclass Roles: 
    Base Concept: 
    Related Concepts: +
    • graphics-document
    • group
    • img
    • graphics-symbol
      • -
    -
    Required Context Role: 
    Required Owned Elements:
    Required States and Properties: 
    Supported States and Properties: 
    Inherited States and Properties: 
    Name From: -
      -
    • author
      • -
    • contents
      • -
    -
    Accessible Name Required:False
    Inherits Name Required:
    Children Presentational:False
    Inherits Presentational: 
    Implicit Value for Role: 
    - -
    - - -
    - graphics-scale -
    -

    A type of guide object, usually a reference for measuring.

    -

    Even though there are several subclasses of graphics-scale, - graphics-scale is not an abstract role as there are situations where a subclass doesn't - meet the authors need. When graphics-scale is used - the aria-roledescription property - can be used to name the guide type - separately from the name and description - for the particular instance of the guide. -

    +
+
Required Context Role: 
Required Owned Elements:
Required States and Properties: 
Supported States and Properties: 
Inherited States and Properties: 
Name From: +
    +
  • author
    • +
  • contents
    • +
+
Accessible Name Required:False
Inherits Name Required:
Children Presentational:False
Inherits Presentational: 
Implicit Value for Role: 
+
+
-

- The preceeding paragraph is dependent on - aria-roledescription being incorporated - into the ARIA 1.1 specification. -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Characteristics:
CharacteristicValue
Is Abstract:False
Superclass Role:graphics-guide
Subclass Roles:
Base Concept:
Related Concepts:
Required Context Role:
Required Owned Elements:
Required States and Properties:
Supported States and Properties: - aria-gtype -
Inherited States and Properties:
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:
Inherits Presentational:
Implicit Value for Role:
- -
-
- graphics-symbol -
-

- A graphic used to convey a simple meaning or category, - where the meaning is more important - than the particular visual appearance. - It may be a component of a larger structured graphic - such as a chart or map. - The symbol itself is an atomic object; - children are presentational. -

-

- When used as part of a structured symbolic language, - the aria-roledescription property - can be used to name the symbol type - separately from the name and description - for the particular instance of the symbol. -

-

- The preceeding paragraph is dependent on - aria-roledescription being incorporated - into the ARIA 1.1 specification. -

-

- To support user agents and assistive technologies - based on the ARIA 1.0 specification, - authors may wish to include the img role - as a fallback value, - in the form role="graphics-symbol img", - if that is not already the default semantic role for the element. -

- 
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Characteristics: +
CharacteristicValue
Is Abstract:False
Superclass Role:graphics-guide
Subclass Roles:
Base Concept:
Related Concepts:
Required Context Role:
Required Owned Elements:
Required States and Properties:
Supported States and Properties: + aria-gtype +
Inherited States and Properties:
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:
Inherits Presentational:
Implicit Value for Role:
+
+
+
+ graphics-symbol +
+

+ A graphic used to convey a simple meaning or category, where the meaning is more important than the particular visual appearance. It may be a component of a larger structured graphic + such as a chart or map. The symbol itself is an atomic object; children are presentational. +

+

+ When used as part of a structured symbolic language, the aria-roledescription property can be used to name the symbol type separately from the name and description for the + particular instance of the symbol. +

+

The preceeding paragraph is dependent on aria-roledescription being incorporated into the ARIA 1.1 specification.

+

+ To support user agents and assistive technologies based on the ARIA 1.0 specification, authors may wish to include the img role as a fallback value, in the form + role="graphics-symbol img", if that is not already the default semantic role for the element. +

+ 
 <!-- Within an HTML document listing a restaurant menu -->
 <h2>Appetizers</h2>
 <ul>
@@ -2157,8 +2188,9 @@ 
Definition of Roles

     </li>
     <!-- … -->
 </ul>
-
- 
+
+ 
 <!-- Within an SVG diagram of an electrical circuit -->
 <g id="lightbulb-1" role="graphics-symbol img" 
    aria-roledescription="load" 
@@ -2175,7 +2207,7 @@ 
Definition of Roles
- 
+            
 <!-- Within an architectural blueprint-style SVG diagram -->
 <g role="graphics-symbol img">
     <title>Door</title>
@@ -2195,217 +2227,196 @@ 
Definition of Roles

 
 
 

-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Characteristics:
CharacteristicValue
Is Abstract: 
Superclass Role:img
Subclass Roles: 
Base Concept: 
Related Concepts:symbol
Required Context Role: 
Required Owned Elements:
Required States and Properties: 
Supported States and Properties: 
Inherited States and Properties: 
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:True
Inherits Presentational: 
Implicit Value for Role: 
-
-
-
- graphics-timedata -
-

Something defined or marked by an instant of time or time interval.

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Characteristics:
CharacteristicValue
Is Abstract:False
Superclass Role:graphics-dataitem
Subclass Roles:
Base Concept:
Related Concepts:
Required Context Role:
Required Owned Elements:
Required States and Properties:
Supported States and Properties:
Inherited States and Properties:
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:
Inherits Presentational:
Implicit Value for Role:
-
-
- -
- img -
-

- The definitive role definition for img is img. -

-

The use of img in the graphics context is slightly different - than that used outside of it due to the semantics available for drawings. - An img can contain - multiple drawing objects or image files - that when viewed together give the impression of a single image. - However, an img represents an indivisible component - within a document for navigation purposes. - If the child elements are arranged - in a semantically rich structure - that users may wish to navigate through, - authors should use a graphics-figure - or graphics-document role instead. -

-

- The element with the img role - may also contain captions and descriptive text within child elements, - if those elements participate in - the accessible name or description calculation for that element. - To ensure that elements with a role of img - are perceivable, - authors MUST provide alternative text or a label - determined by the accessible name calculation. - Authors SHOULD also provide an accessible description - that conveys the complete meaning of the image. - If the image is purely symbolic, - and the visual details are not relevant, - the graphics-symbol role is more appropriate. - If the image is used as a direct substitute - for a short word or phrase within a sentence, - the text role is appropriate. -

-

- The img role was first defined in ARIA 1.0. - This specification modifies that definition - in a backwards-compatible way, - to clarify the distinction between images - and other graphical roles. -

- 
+          -->
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Characteristics: +
CharacteristicValue
Is Abstract:False
Superclass Role:graphics-dataitem
Subclass Roles:
Base Concept:
Related Concepts:
Required Context Role:
Required Owned Elements:
Required States and Properties:
Supported States and Properties:
Inherited States and Properties:
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:
Inherits Presentational:
Implicit Value for Role:
+
+
+ +
+ img +
+

The definitive role definition for img is img.

+

+ The use of img in the graphics context is slightly different than that used outside of it due to the semantics available for drawings. An img can contain + multiple drawing objects or image files that when viewed together give the impression of a single image. However, an img represents an indivisible + component within a document for navigation purposes. If the child elements are arranged in a semantically rich structure that users may wish to navigate through, authors should use a + graphics-figure or graphics-document role instead. +

+

+ The element with the img role may also contain captions and descriptive text within child elements, if those elements participate in the accessible name or description + calculation for that element. To ensure that elements with a role of img are perceivable, authors MUST provide alternative text or a label determined by the + accessible name calculation. Authors SHOULD also provide an accessible description that conveys the complete meaning of the image. If the image is purely + symbolic, and the visual details are not relevant, the graphics-symbol role is more appropriate. If the image is used as a direct substitute for a short word or phrase + within a sentence, the text role is appropriate. +

+

+ The img role was first defined in ARIA 1.0. This specification modifies that definition in a backwards-compatible way, to clarify the distinction between images and other + graphical roles. +

+ 
 <!-- Within an HTML 5 document, an inline SVG
     may sometimes represent an atomic img -->
 <p>A repeating SVG gradient is defined using the
@@ -2430,7 +2441,7 @@ 
Definition of Roles
- 
+            
 <!-- Within the fallback DOM dynamically constructed
      for an HTML 5 canvas game,
      elements may represent the different images
@@ -2451,203 +2462,217 @@ 
Definition of Roles

    </p>
    <!-- more DOM elements representing game controls -->
 </canvas>
-

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Characteristics:
CharacteristicValue
Is Abstract: 
Superclass Role:section
Subclass Roles:Placeholder
Base Concept: 
Related Concepts: - -
Required Context Role: 
Required Owned Elements: 
Required States and Properties: 
Supported States and Properties: 
Inherited States and Properties:Placeholder
Name From:author
Accessible Name Required:True
Inherits Name Required: 
Children Presentational:True
Inherits Presentational: 
-
-
-
-
-
-

States and Properties

-

WAI-ARIA provides a collection of accessibility state and properties which are used to support platform accessibility APIs on various - operating system platforms. Assistive technologies may access this information through an exposed user agent DOM or through a mapping - to the platform accessibility API. When combined with roles, the user agent can supply the assistive technologies with user interface - information to convey to the user at any time. Changes in states or properties will result in a notification to assistive technologies, - which could alert the user that a change has occurred.

-

Assistive technology may use aria-gtype as an adjective for the role in name calculation.

-
-

Managing navigation

-

Roles, states and properties can be used to manage graphics navigation. Properties can be used to manage navigation behavior and - differentiate between graphics features with the same role and same semantic parent. Customized navigation behavior may be needed when - statistics produce multiple data columns. For example, data for a box and whisker plot are produced by statistics, and - the statistic produces columns for the fence, box, median and outliers. Outliers can be classified in more than one way and - different statistics can produce different flavors of boxes and fences and outliers. The semantics of the statistic need to be accurately - communicated to the user during exploration. Charts, instructional diagrams, chemical models and maps are examples of graphics that - may need customizable navigation. -

-

The following properties can modify navigation behavior: -

    -
  • aria-gtype
    • -
-

- It has not been decided what mechanism, if any, will cue navigation changes. -

-
-
-

Definitions of States and Properties

-

Below is a list of properties that can be used with graphics roles. A detailed definition of each state and property - follows this compact list.

-

Placeholder for index of states and properties

-
- -
- aria-categories -
-

A list of categories.

-
- - - - - - - - - - - - - - - - - - - - - - - - - - -
Characteristics:
CharacteristicValue
Related Concepts:
Used in Roles:Placeholder
Inherits into Roles:Placeholder
Value:string
-
-
- -
- aria-gtype -
-

A differentiator for graphics features with the same role and semantic parent.

-
- - - - - - - - - - - - - - - - - - - - - - - - - - -
Characteristics:
CharacteristicValue
Related Concepts:
Used in Roles:Placeholder
Inherits into Roles:Placeholder
Value:string
-
- -
-
-
-

Schemata

-

The HTML Working Group has incorporated the WAI-ARIA attributes into HTML 5. Official support for WAI-ARIA in HTML is provided in that specification.

-

Validation support for the roles defined in this module will be added once the specification reaches recommendation.

-

For information on incorporating WAI-ARIA into other grammars, refer to Appendix A of [[!WAI-ARIA]]

-

Review whether any additional schemata are necessary for this module.

-
-
-

Change Log

-

A detailed history of changes committed is available from the github repository for this document. When drafts of this document begin to stabilise, human-readable change logs will be incorporated.

- -
-
-

WAI-ARIA Role, State, and Property Quick Reference

-

The following table provides a quick reference to the supported states and properties for all WAI-ARIA roles that may be used in markup.

-
-

In addition to the states and properties shown in the table, the following global states and properties are supported on all roles.

-

Placeholder for global states and properties

-
-

Placeholder for quick reference table

-
-
-

Acknowledgments

-

The following people contributed to the development of this document.

-
-

Participants active in the SVG accessibility task force at the time of publication

-
    -
  • Amelia Bellamy-Royds (Invited expert)
    • -
  • Fred Esch (IBM Corporation)
    • -
  • Charles McCathieNevile (Yandex)
    • -
  • Charu Pandhi (IBM Corporation)
    • -
  • Doug Schepers (W3C Staff)
    • -
  • Richard Schwerdtfeger (Knowbility)
    • -
  • Léonie Watson (The Paciello Group)
    • -
  • Jason White (Educational Testing Service)
    • -
-
-
-

Participants active in the PFWG at the time of publication

-
    -
  • Christy Blew (University of Illinois at Urbana-Champaign)
    • -
  • David Bolter (Mozilla Foundation)
    • -
  • Michael Cooper (W3C/MIT)
    • -
  • James Craig (Apple Inc.)
    • -
  • Joanmarie Diggs (Igalia)
    • -
  • Fred Esch (IBM Corporation)
    • -
  • Steve Faulkner (The Paciello Group)
    • -
  • John Foliot (Invited Expert)
    • -
  • Christopher Gallelo (Microsoft Corporation)
    • -
  • Bryan Garaventa (SSB BART Group)
    • -
  • Scott González (JQuery Foundation)
    • -
  • Billy Gregory (The Paciello Group)
    • -
  • Karl Groves (The Paciello Group)
    • -
  • Jon Gunderson (University of Illinois at Urbana-Champaign)
    • -
  • Birkir Gunnarsson (Deque Systems, Inc.)
    • -
  • Markus Gylling (DAISY Consortium)
    • -
  • Mona Heath (University of Illinois at Urbana-Champaign)
    • -
  • Susann Keohane (IBM Corporation)
    • -
  • Matthew King (IBM Corporation)
    • -
  • Jason Kiss (Department of Internal Affairs, New Zealand Government)
    • -
  • Dominic Mazzoni (Google, Inc.)
    • -
  • Shane McCarron (Invited Expert, Aptest)
    • -
  • Charles McCathieNevile (Yandex)
    • -
  • Mary Jo Mueller (IBM Corporation)
    • -
  • James Nurthen (Oracle Corporation)
    • -
  • Janina Sajka (Invited Expert, The Linux Foundation)
    • -
  • Joseph Scheuhammer (Invited Expert, Inclusive Design Research Centre, OCAD University)
    • -
  • Stefan Schnabel (SAP AG)
    • -
  • Richard Schwerdtfeger (Knowbility)
    • -
  • Lisa Seeman (Invited Expert)
    • -
  • Cynthia Shelly (Microsoft Corporation)
    • -
  • Alexander Surkov (Mozilla Foundation)
    • -
  • Léonie Watson (The Paciello Group)
    • -
  • Jason White (Educational Testing Service)
    • -
  • Marco Zehe (Mozilla Foundation)
    • -
  • Gottfried Zimmermann (Invited Expert, Access Technologies Group)
    • -
-
-
-
- +
+
+

WAI-ARIA Role, State, and Property Quick Reference

+

The following table provides a quick reference to the supported states and properties for all WAI-ARIA roles that may be used in markup.

+
+

In addition to the states and properties shown in the table, the following global states and properties are supported on all roles.

+

Placeholder for global states and properties

+
+

Placeholder for quick reference table

+
+
+

Acknowledgments

+

The following people contributed to the development of this document.

+
+

Participants active in the SVG accessibility task force at the time of publication

+
    +
  • Amelia Bellamy-Royds (Invited expert)
    • +
  • Fred Esch (IBM Corporation)
    • +
  • Charles McCathieNevile (Yandex)
    • +
  • Charu Pandhi (IBM Corporation)
    • +
  • Doug Schepers (W3C Staff)
    • +
  • Richard Schwerdtfeger (Knowbility)
    • +
  • Léonie Watson (The Paciello Group)
    • +
  • Jason White (Educational Testing Service)
    • +
+
+
+

Participants active in the PFWG at the time of publication

+
    +
  • Christy Blew (University of Illinois at Urbana-Champaign)
    • +
  • David Bolter (Mozilla Foundation)
    • +
  • Michael Cooper (W3C/MIT)
    • +
  • James Craig (Apple Inc.)
    • +
  • Joanmarie Diggs (Igalia)
    • +
  • Fred Esch (IBM Corporation)
    • +
  • Steve Faulkner (The Paciello Group)
    • +
  • John Foliot (Invited Expert)
    • +
  • Christopher Gallelo (Microsoft Corporation)
    • +
  • Bryan Garaventa (SSB BART Group)
    • +
  • Scott González (JQuery Foundation)
    • +
  • Billy Gregory (The Paciello Group)
    • +
  • Karl Groves (The Paciello Group)
    • +
  • Jon Gunderson (University of Illinois at Urbana-Champaign)
    • +
  • Birkir Gunnarsson (Deque Systems, Inc.)
    • +
  • Markus Gylling (DAISY Consortium)
    • +
  • Mona Heath (University of Illinois at Urbana-Champaign)
    • +
  • Susann Keohane (IBM Corporation)
    • +
  • Matthew King (IBM Corporation)
    • +
  • Jason Kiss (Department of Internal Affairs, New Zealand Government)
    • +
  • Dominic Mazzoni (Google, Inc.)
    • +
  • Shane McCarron (Invited Expert, Aptest)
    • +
  • Charles McCathieNevile (Yandex)
    • +
  • Mary Jo Mueller (IBM Corporation)
    • +
  • James Nurthen (Oracle Corporation)
    • +
  • Janina Sajka (Invited Expert, The Linux Foundation)
    • +
  • Joseph Scheuhammer (Invited Expert, Inclusive Design Research Centre, OCAD University)
    • +
  • Stefan Schnabel (SAP AG)
    • +
  • Richard Schwerdtfeger (Knowbility)
    • +
  • Lisa Seeman (Invited Expert)
    • +
  • Cynthia Shelly (Microsoft Corporation)
    • +
  • Alexander Surkov (Mozilla Foundation)
    • +
  • Léonie Watson (The Paciello Group)
    • +
  • Jason White (Educational Testing Service)
    • +
  • Marco Zehe (Mozilla Foundation)
    • +
  • Gottfried Zimmermann (Invited Expert, Access Technologies Group)
    • +
+
+
+
+ diff --git a/index.html b/index.html index 49de44e..0d40b4c 100644 --- a/index.html +++ b/index.html @@ -1,408 +1,444 @@ - - -WAI-ARIA Graphics Module - - - - - - - + + + + + + - - - -
-

Assistive technologies need semantic information about the structures and expected behaviors of a document in order to convey appropriate information to persons with disabilities. This specification defines a WAI-ARIA 1.1 [[WAI-ARIA-1.1]] module of core roles specific to web graphics. These semantics allow an author to express the logical structure of the graphic to assistive technologies in order improve accessibility of graphics. Assistive technologies could then enable semantic navigation and adapt styling and interactive features, to provide an optimal experience for the audience. These features complement the graphics and document structure elements defined by HTML [[HTML52]] and SVG [[SVG2]].

-

This document is part of the WAI-ARIA suite described in the WAI-ARIA Overview.

-
-
-

This is an Editor's Draft of WAI-ARIA Graphics Module 1.0 by the SVG Accessibility Taskforce, a joint task force of the Accessible Rich Internet Applications Working Group and the SVG Working Group.

-

Feedback on any aspect of the specification is accepted. For this publication, the SVG Accessibility Task Force particularly seeks feedback on the following questions:

- -

To comment, file an issue in the W3C graphics-aria GitHub repository. If this is not feasible, send email to public-aria@w3.org (comment archive). In-progress updates to the document may be viewed in the publicly visible editors' draft.

-
-
-
-
-

Introduction

-

WAI-ARIA is a technical specification that provides a framework to improve the accessibility and interoperability of web content and applications. It enables web browsers to map the accessibility semantics in web content to platform-specific accessibility APIs. This enables web content to be interoperable with platform assistive technologies, similar to native platform applications, without requiring authors to include platform dependencies.

-

This specification is a modular extension of WAI-ARIA [[WAI-ARIA-1.1]] designed to support graphics. The goals of this specification include:

- -

This specification defines the core roles that would be used in all structured graphics or diagrams. - It establishes the default roles that can be used to describe graphical markup elements such as shapes and canvases. - In combination with WAI-ARIA attributes to provide alternative text and to indicate relationships between elements, this provides a framework for annotating many figures and diagrams. - Future work will expand on this framework to enable more detailed annotation of data-rich graphics such as charts or maps.

-

For a more detailed explanation of WAI-ARIA please refer to the WAI-ARIA Introduction and how it applies to Rich Internet Application Accessibility.

- -
-

Target Audience

-

This specification defines a module of WAI-ARIA for graphics, consisting of graphics-specific element roles. It impacts several audiences:

-
    -
  • User agents that process content containing WAI-ARIA and graphics WAI-ARIA features;
    • -
  • Assistive technologies that provide specialized reading experiences to users with disabilities;
    • -
  • Authors of web graphics;
    • -
  • Authoring tools that help authors create conforming graphics; and
    • -
  • Conformance checkers, that verify appropriate use of WAI-ARIA and this WAI-ARIA Graphics module.
    • -
-

Each conformance requirement indicates the audience to which it applies.

- -
- -
-

User Agent Support

-

This module follows the general User Agent support principles defined in WAI-ARIA [[WAI-ARIA-1.1]]. - The roles defined here do not require any change in behavior by user agents other than in the information exposed to the accessibility API. - However, the semantics defined here provide the ability for user agents to enhance the general user interface presented to readers. - For example, a user agent may provide alternative keyboard navigation suitable to a graphical environment, or may allow users to extract a copy of a graphic from a larger document.

-
- -
-

Co-Evolution of WAI-ARIA and Host Languages

-

The WAI-ARIA Graphics module follows the model for co-evolution of WAI-ARIA and host languages defined in WAI-ARIA [[WAI-ARIA-1.1]]. It is intended to augment semantics in supporting languages like HTML [[HTML52]], SVG [[SVG2]] and EPUB, or to be used as an accessibility enhancement technology in other markup-based languages that do not explicitly include support for ARIA. - WAI-ARIA roles clarify semantics to assistive technologies when authors create new types of objects, via style and script, or use markup languages which describe the visual appearance of a document rather than its meaning.

-

Although markup languages may provide some of these semantics natively, it is expected that there will be a persistent need for the semantics provided by the WAI-ARIA Graphics module. - Some host languages exist to create semantics for features other than the user interface. For example, SVG expresses the semantics behind production of graphical objects, not of user interface components that those objects may represent. Host languages such as these might, by design, not provide native semantics that map to all of this specification's features. In these host languages, the WAI-ARIA Graphics module could be adopted as a long-term approach to add semantic information.

-
- -
-

Authoring Practices

-
-

Authoring Tools

-

Many of the requirements in the definitions of the WAI-ARIA and Graphics WAI-ARIA roles, states and properties can be checked automatically during the development process, similar to other quality control processes used for validating code. To assist authors who are creating graphics, these tools can compare the semantic structure of Graphics WAI-ARIA roles from the DOM to that defined in this specification and notify the author of errors or simply create templates that enforce that structure.

-
- -
-

Testing Practices and Tools

-

The accessibility of interactive content cannot be confirmed by static checks alone. Developers of interactive content should test for device-independent access to widgets and applications, and should verify accessibility API access to all content and changes during user interaction.

-
-
- -
-

Assistive Technologies

-

Programmatic access to accessibility semantics is essential for assistive technologies. For more information, refer to the Assistive Technologies section in WAI-ARIA [[WAI-ARIA-1.1]].

-

For the graphics roles in particular, two categories of assistive technology are particularly relevant, but have different needs:

+ } + + + +
+

+ Assistive technologies need semantic information about the structures and expected behaviors of a document in order to convey appropriate information to persons with disabilities. This + specification defines a WAI-ARIA 1.1 [[WAI-ARIA-1.1]] module of core roles + specific to web graphics. These semantics allow an author to express the logical structure of the graphic to assistive technologies in order improve accessibility of graphics. Assistive + technologies could then enable semantic navigation and adapt styling and interactive features, to provide an optimal experience for the audience. These features complement the graphics and + document structure elements defined by HTML [[HTML52]] and SVG [[SVG2]]. +

+

+ This document is part of the WAI-ARIA suite described in the + WAI-ARIA Overview. +

+
+
+

+ This is an Editor's Draft of WAI-ARIA Graphics Module 1.0 by the + SVG Accessibility Taskforce, a joint task force of the + Accessible Rich Internet Applications Working Group and the SVG Working Group. +

+

+ Feedback on any aspect of the specification is accepted. For this publication, the SVG Accessibility Task Force particularly seeks feedback on the + following questions: +

+
    +
  • Are proposed roles clear and appropriate to the needs of interactive graphics?
    • +
  • Is the relationship of this specification to WAI-ARIA 1.1 clear?
    • +
+

+ To comment, file an issue in the W3C graphics-aria GitHub repository. If this is not feasible, send email to + public-aria@w3.org (comment archive). + In-progress updates to the document may be viewed in the publicly visible editors' draft. +

+
+
+
+

Introduction

+

+ WAI-ARIA is a technical specification that provides a framework to improve the accessibility and interoperability of web content and + applications. It enables web browsers to map the accessibility semantics in web content to platform-specific accessibility APIs. This enables web content to be interoperable with platform + assistive technologies, similar to native platform applications, without requiring authors to include platform dependencies. +

+

+ This specification is a modular extension of WAI-ARIA [[WAI-ARIA-1.1]] designed to support graphics. The goals of this specification + include: +

+
    +
  • + Expanding WAI-ARIA to produce semantic extensions to support structured graphics such as charts, graphs, maps, technical drawings and scientific diagrams. It has applicability to both + Scalable Vector Graphics as well as HTML 5 Canvas and graphics produced with CSS styling of HTML and other markup languages. +
    • +
  • Align with a new governance model for modularization and extensions to WAI-ARIA.
    • +
  • Provide structural semantics extensions that will support both assistive technologies and enable semantic navigation, alternative styling, and interactivity support.
    • +
  • + Work in harmony with SVG 2 and ARIA 1.1 to get consistent working accessibility infrastructure, on par with WAI-ARIA and HTML 5.2, + across all the major browsers. +
    • +
+

+ This specification defines the core roles that would be used in all structured graphics or diagrams. It establishes the default roles that can be used to describe graphical markup elements + such as shapes and canvases. In combination with WAI-ARIA attributes to provide alternative text and to indicate relationships between elements, this provides a framework for annotating many + figures and diagrams. Future work will expand on this framework to enable more detailed annotation of data-rich graphics such as charts or maps. +

+

+ For a more detailed explanation of WAI-ARIA please refer to the + WAI-ARIA Introduction and how it applies to Rich Internet Application Accessibility. +

+ +
+

Target Audience

+

+ This specification defines a module of WAI-ARIA for graphics, consisting of graphics-specific element roles. It impacts several audiences: +

    -
  • Text-based presentations, such as screen readers, braille displays, and text-only displays or printers. These technologies need to replace a complex graphic with semantic text descriptions, preserving any meaningful structure and relationships between components. -
    • -
  • Alternative graphical presentations, such as colour-adjusted displays, screen magnifiers, large print documents, or embossing printers with graphic support. These technologies need to distinguish between graphical features which are primarily decorative and those which are essential for conveying the meaning of the content.
    • +
  • + User agents that process content containing WAI-ARIA and graphics + WAI-ARIA features; +
    • +
  • Assistive technologies that provide specialized reading experiences to users with disabilities;
    • +
  • Authors of web graphics;
    • +
  • Authoring tools that help authors create conforming graphics; and
    • +
  • + Conformance checkers, that verify appropriate use of WAI-ARIA and this + WAI-ARIA Graphics module. +
-

The role descriptions suggest which features of an element with that role are considered semantically important and should be conveyed to the reader whenever possible.

-
-
-
-

Conformance

-

The main content of this specification is normative and defines requirements that impact conformance claims. Introductory material, appendices, sections marked as "non-normative" and their subsections, diagrams, examples, and notes are informative (non-normative). Non-normative material provides advisory information to help interpret the guidelines but does not create requirements that impact a conformance claim.

-

Normative sections provide requirements that user agents must follow for an implementation to conform to this specification. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in Keywords for use in RFCs to indicate requirement levels [[!RFC2119]]. RFC-2119 keywords are formatted in uppercase and contained in an element with class="rfc2119". When the keywords shown above are used, but do not share this format, they do not convey formal information in the RFC 2119 sense, and are merely explanatory, i.e., informative. As much as possible, such usages are avoided in this specification.

-

Normative sections provide requirements that authors, user agents and assistive technologies MUST follow for an implementation to conform to this specification.

-

Non-normative (informative) sections provide information useful to understanding the specification. Such sections may contain examples of recommended practice, but it is not required to follow such recommendations in order to conform to this specification.

-
-
-

Graphics Roles

-

- This section defines additions to the - WAI-ARIA - role taxonomy - and describes the characteristics and properties of all roles. - See ARIA Roles for descriptions - of the fields provided by this module. -

-

- Authors are given the ability to influence what is presented - to assistive technologies and to influence navigation through - the use of roles and properties. - This includes the ability to mark elements as having no semantic importance. - With graphics, there are many - cases where presenting and navigating every element will make the - graphic harder to understand and use. -

-

- Authors may mark elements for exclusion - from the semantic representation of the document - (the accessibility tree) by assigning - the role none or presentation. - The element with this role should be treated transparently - by assistive technologies, as if its children or text content - were directly contained by its parent element. - In addition, certain roles, - such as img or graphics-symbol, - when assigned to a parent element, will cause all child - DOM structure to be omitted from the accessibility tree. - This is indicated by the "Children Presentational" - value in the role characteristics table. - Finally, the native semantics of the graphics language - may also default to ignoring DOM structure that does not have - semantic data attached; for SVG, this is defined in the SVG Accessibility API Mappings specification [[SVG-AAM-1.0]]. -

-

- In all cases, to be considered presentational, an element must not be interactive - and must not be assigned any accessible properties or alternative text. - A role of none or presentation will be ignored - for interactive elements or those with WAI-ARIA states and properties.

-
-

Definition of Roles

-

- Below is an alphabetical list of the - WAI-ARIA - roles defined in this specification. - They would normally be used in combination with other roles - defined in WAI-ARIA - to annotate graphics within documents and rich internet applications [[WAI-ARIA-1.1]]. -

- -

Placeholder for compact list of roles

- - -
- graphics-document -
+

Each conformance requirement indicates the audience to which it applies.

+ +
+ +
+

User Agent Support

+

+ This module follows the general User Agent support principles defined in WAI-ARIA [[WAI-ARIA-1.1]]. The roles defined here do not + require any change in behavior by user agents other than in the information exposed to the accessibility API. However, the semantics defined here provide the ability for user agents + to enhance the general user interface presented to readers. For example, a user agent may provide alternative keyboard navigation suitable to a graphical environment, or may allow users to + extract a copy of a graphic from a larger document. +

+
+ +
+

Co-Evolution of WAI-ARIA and Host Languages

- A type of document in which - the visual appearance or layout of content conveys meaning. + The WAI-ARIA Graphics module follows the model for + co-evolution of WAI-ARIA and host languages defined in WAI-ARIA + [[WAI-ARIA-1.1]]. It is intended to augment semantics in supporting languages like HTML [[HTML52]], SVG [[SVG2]] and EPUB, or to be used as an accessibility enhancement technology in other + markup-based languages that do not explicitly include support for ARIA. WAI-ARIA roles clarify semantics to assistive technologies when authors create new types of objects, via style + and script, or use markup languages which describe the visual appearance of a document rather than its meaning.

- Similar to other document types, - the graphics-document role applies to the root element of - a region of the page containing related information, - where the user's primary interaction mode is expected to be - browsing the document rather than controlling an application. - The element with this role - may be the root element of the document file, - or of a nested structure within it. + Although markup languages may provide some of these semantics natively, it is expected that there will be a persistent need for the semantics provided by the + WAI-ARIA Graphics module. Some host languages exist to create semantics for features other than the user interface. For example, + SVG expresses the semantics behind production of graphical objects, not of user interface components that those objects may represent. Host languages such as these might, by design, not + provide native semantics that map to all of this specification's features. In these host languages, the WAI-ARIA Graphics module + could be adopted as a long-term approach to add semantic information.

+
+ +
+

Authoring Practices

+
+

Authoring Tools

+

+ Many of the requirements in the definitions of the WAI-ARIA and Graphics + WAI-ARIA roles, states and properties can be checked + automatically during the development process, similar to other quality control processes used for validating code. To assist authors who are creating graphics, these tools can compare the + semantic structure of Graphics WAI-ARIA roles from the DOM to that defined in this + specification and notify the author of errors or simply create templates that enforce that structure. +

+
+ +
+

Testing Practices and Tools

+

+ The accessibility of interactive content cannot be confirmed by static checks alone. Developers of interactive content should test for device-independent access to + widgets and applications, and should verify accessibility API access to all content and changes during user + interaction. +

+
+
+ +
+

Assistive Technologies

- The graphics-document may be distinguished - from similar roles as follows: + Programmatic access to accessibility semantics is essential for assistive technologies. For more information, refer to the + Assistive Technologies section in WAI-ARIA [[WAI-ARIA-1.1]].

+

For the graphics roles in particular, two categories of assistive technology are particularly relevant, but have different needs:

    -

  • - Relative to other documents, a graphics-document - is distinguished by the semantic importance of its - visual (usually two-dimensional) representation. - User agents and assistive technologies - SHOULD take this into consideration - when supporting navigation of the graphic. - Accessibility technologies that re-format or re-style a document - SHOULD NOT alter the layout of a graphics-document - except in ways that are consistent - with the semantic roles and relationships of its content. -

    • -

  • - Relative to an img, a graphics-document - is distinguished by the structured nature of its content. - Its child elements may have semantic meaning, - and may include links or other interactive widgets. -

    • -

  • - Relative to a graphics-object, - a graphics-document is self-contained. - Its meaning persists when separated from surrounding content. - The element with the graphics-document role defines - the scope and context for interpretation of the child content. -

    • +
  • + Text-based presentations, such as screen readers, braille displays, and text-only displays or printers. These technologies need to replace a complex graphic with semantic text + descriptions, preserving any meaningful structure and relationships between components. +
    • +
  • + Alternative graphical presentations, such as colour-adjusted displays, screen magnifiers, large print documents, or embossing printers with graphic support. These technologies need to + distinguish between graphical features which are primarily decorative and those which are essential for conveying the meaning of the content. +
+

The role descriptions suggest which features of an element with that role are considered semantically important and should be conveyed to the reader whenever possible.

+
+
+
+

Conformance

+

+ The main content of this specification is normative and defines requirements that impact conformance claims. Introductory material, appendices, sections marked as + "non-normative" and their subsections, diagrams, examples, and notes are informative (non-normative). Non-normative material provides advisory information to help + interpret the guidelines but does not create requirements that impact a conformance claim. +

+

+ Normative sections provide requirements that user agents must follow for an implementation to conform to this specification. The keywords MUST, + MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, + RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in + Keywords for use in RFCs to indicate requirement levels [[!RFC2119]]. RFC-2119 keywords are formatted in uppercase and + contained in an element with class="rfc2119". When the keywords shown above are used, but do not share this format, they do not convey formal information in the RFC 2119 sense, + and are merely explanatory, i.e., informative. As much as possible, such usages are avoided in this specification. +

+

Normative sections provide requirements that authors, user agents and assistive technologies MUST follow for an implementation to conform to this specification.

+

+ Non-normative (informative) sections provide information useful to understanding the specification. Such sections may contain examples of recommended practice, but it is not required to follow + such recommendations in order to conform to this specification. +

+
+
+

Graphics Roles

+

+ This section defines additions to the + WAI-ARIA + role taxonomy and describes the characteristics and properties of all roles. See + ARIA Roles for descriptions of the fields provided by this module. +

+

+ Authors are given the ability to influence what is presented to assistive technologies and to influence navigation through the use of roles and properties. This includes the ability to mark + elements as having no semantic importance. With graphics, there are many cases where presenting and navigating every element will make the graphic harder to understand and use. +

+

+ Authors may mark elements for exclusion from the semantic representation of the document (the accessibility tree) by assigning the role none or presentation. The + element with this role should be treated transparently by assistive technologies, as if its children or text content were directly contained by its parent element. In addition, certain roles, + such as img or graphics-symbol, when assigned to a parent element, will cause all child DOM structure to be omitted from the accessibility tree. This is indicated by + the "Children Presentational" value in the role characteristics table. Finally, the native semantics of the graphics language may also default to ignoring DOM structure that does not have + semantic data attached; for SVG, this is defined in the SVG Accessibility API Mappings specification [[SVG-AAM-1.0]]. +

+

+ In all cases, to be considered presentational, an element must not be interactive and must not be assigned any accessible properties or alternative text. A role of none or + presentation will be ignored for interactive elements or those with WAI-ARIA states and properties. +

+
+

Definition of Roles

- In general, authors SHOULD use the graphics-document role - for structured graphics such as - charts, maps, diagrams, technical drawing, blue prints and instructional graphics. - However, if a single large graphic has discrete regions - that may be safely re-arranged without sacrificing meaning, - each of those regions SHOULD be a distinct graphics-document. - An alternative role (such as figure) - may be used to group them together. - One graphics-document may also be nested inside another, - for example a bar chart that is embedded in a map - or a matrix of chart panels - should have a role of graphics-document. - The nested document provides encapsulation; - navigation between components of - the inner and outer graphics should be explicit. -

-
-

- To support user agents and assistive technologies - based on the ARIA 1.0 specification, - authors may wish to include the document role - as a fallback value, - in the form role="graphics-document document". -

-

- Future specifications may define more specific roles - for particular types of graphical documents with - special semantic structures. Those more specific roles - would be subclasses of graphics-document. -

-
-
-
-

Other Roles for Graphics

-

The following core ARIA roles, defined in ARIA 1.1 [[WAI-ARIA-1.1]], are also - relevant for annotating graphics: -

-
    -
  • - img (image) defines a single graphic - that is perceived as an indivisible whole. - Unlike a graphics-document, - an image cannot have navigable or interactive child content. - Unlike a graphics-symbol, - an image may require a detailed text description - to fully convey its meaning to non-visual users. -
    • -
  • - figure defines a container element - for content (including graphics) that is a key part - of the containing document but is outside the - normal reading stream. - A figure will often contain one or more elements - with the img or graphics-document roles, - but may also contain text captions, credits, or other related content. -
    • -
-

- The following examples demonstrate appropriate use of - img, figure, and graphics-document - in a document. -

- - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Characteristics: +
CharacteristicValue
Is Abstract: 
Superclass Role:img
Subclass Roles: 
Base Concept: 
Related Concepts:symbol
Required Context Role: 
Required Owned Elements:
Required States and Properties: 
Supported States and Properties: 
Inherited States and Properties: 
Name From:author
Accessible Name Required:True
Inherits Name Required:
Children Presentational:True
Inherits Presentational: 
Implicit Value for Role: 
+ +
+
+

Other Roles for Graphics

+

The following core ARIA roles, defined in ARIA 1.1 [[WAI-ARIA-1.1]], are also relevant for annotating graphics:

+
    +
  • + img (image) defines a single graphic that is perceived as an indivisible whole. Unlike a graphics-document, an image cannot have navigable or interactive child + content. Unlike a graphics-symbol, an image may require a detailed text description to fully convey its meaning to non-visual users. +
    • +
  • + figure defines a container element for content (including graphics) that is a key part of the containing document but is outside the normal reading stream. A figure will often + contain one or more elements with the img or graphics-document roles, but may also contain text captions, credits, or other related content. +
    • +
+

+ The following examples demonstrate appropriate use of + img, figure, and graphics-document + in a document. +

- -
+            
+
+ -
-
-
-

States and Properties

-

WAI-ARIA provides a collection of accessibility state and properties which are used to support platform accessibility APIs on various - operating system platforms. Assistive technologies may access this information through an exposed user agent DOM or through a mapping - to the platform accessibility API. When combined with roles, the user agent can supply the assistive technologies with user interface - information to convey to the user at any time. Changes in states or properties will result in a notification to assistive technologies, - which could alert the user that a change has occurred.

- -
-
-

Change Log

-

The full commit history to WAI-ARIA Graphics Module 1.0 is available.

-
-

Substantive changes since the last public working draft

-
    -
  • 2017-11-15: Change superclass for graphics-object to img and graphics-symbol to group.
    • - -
-
-
-

Other substantive changes since the First Public Working Draft

-
    -
  • 2016-01-26: changed superclass of graphics-doc to structure.
    • -
  • 2016-04-28: removed reference to role="none" or "presentation".
    • -
  • 2016-05-02: Change graphics-doc to graphics-document.
    • -
  • 2016-05-07: clarify limitations of presentational role; mention SVG 2 next to HTML 5 in section on Schemata.
    • - -
-
-
-
-

Acknowledgments

-

The following people contributed to the development of this document.

-
-

Participants active in the SVG accessibility task force at the time of publication

-
    -
  • Amelia Bellamy-Royds (Invited expert)
    • -
  • Fred Esch (IBM Corporation)
    • -
  • Charles McCathieNevile (Yandex)
    • -
  • Charu Pandhi (IBM Corporation)
    • -
  • Doug Schepers (W3C Staff)
    • -
  • Richard Schwerdtfeger (Knowbility)
    • -
  • Léonie Watson (The Paciello Group)
    • -
  • Jason White (Educational Testing Service)
    • -
-
-
-

Participants active in the ARIA WG at the time of publication

-
    -
  • David Bolter (Mozilla Foundation)
    • -
  • Michael Cooper (W3C/MIT)
    • -
  • James Craig (Apple Inc.)
    • -
  • Joanmarie Diggs (Igalia)
    • -
  • John Foliot (Invited Expert)
    • -
  • Christopher Gallelo (Microsoft Corporation)
    • -
  • Bryan Garaventa (SSB BART Group)
    • -
  • Jon Gunderson (University of Illinois at Urbana-Champaign)
    • -
  • Matthew King (IBM Corporation)
    • -
  • Dominic Mazzoni (Google, Inc.)
    • -
  • Shane McCarron (Invited Expert, Aptest)
    • -
  • James Nurthen (Oracle Corporation)
    • -
  • Janina Sajka (Invited Expert, The Linux Foundation)
    • -
  • Stefan Schnabel (SAP AG)
    • -
  • Lisa Seeman (Invited Expert)
    • -
  • Alexander Surkov (Mozilla Foundation)
    • -
  • Jason White (Educational Testing Service)
    • -
-
-
-
- + + +
+
+
+

States and Properties

+

+ WAI-ARIA provides a collection of accessibility state and properties which are used to support platform accessibility APIs on various operating system platforms. Assistive technologies may + access this information through an exposed user agent DOM or through a mapping to the platform accessibility API. When combined with roles, the user agent can supply the assistive technologies + with user interface information to convey to the user at any time. Changes in states or properties will result in a notification to assistive technologies, which could alert the user that a + change has occurred. +

+
+
+

Change Log

+

The full commit history to WAI-ARIA Graphics Module 1.0 is available.

+
+

Substantive changes since the last public working draft

+
    +
  • 2017-11-15: Change superclass for graphics-object to img and graphics-symbol to group.
    • + +
+
+
+

Other substantive changes since the First Public Working Draft

+
    +
  • 2016-01-26: changed superclass of graphics-doc to structure.
    • +
  • 2016-04-28: removed reference to role="none" or "presentation".
    • +
  • 2016-05-02: Change graphics-doc to graphics-document.
    • +
  • 2016-05-07: clarify limitations of presentational role; mention SVG 2 next to HTML 5 in section on Schemata.
    • + +
+
+
+
+

Acknowledgments

+

The following people contributed to the development of this document.

+
+

Participants active in the SVG accessibility task force at the time of publication

+
    +
  • Amelia Bellamy-Royds (Invited expert)
    • +
  • Fred Esch (IBM Corporation)
    • +
  • Charles McCathieNevile (Yandex)
    • +
  • Charu Pandhi (IBM Corporation)
    • +
  • Doug Schepers (W3C Staff)
    • +
  • Richard Schwerdtfeger (Knowbility)
    • +
  • Léonie Watson (The Paciello Group)
    • +
  • Jason White (Educational Testing Service)
    • +
+
+
+

Participants active in the ARIA WG at the time of publication

+
    +
  • David Bolter (Mozilla Foundation)
    • +
  • Michael Cooper (W3C/MIT)
    • +
  • James Craig (Apple Inc.)
    • +
  • Joanmarie Diggs (Igalia)
    • +
  • John Foliot (Invited Expert)
    • +
  • Christopher Gallelo (Microsoft Corporation)
    • +
  • Bryan Garaventa (SSB BART Group)
    • +
  • Jon Gunderson (University of Illinois at Urbana-Champaign)
    • +
  • Matthew King (IBM Corporation)
    • +
  • Dominic Mazzoni (Google, Inc.)
    • +
  • Shane McCarron (Invited Expert, Aptest)
    • +
  • James Nurthen (Oracle Corporation)
    • +
  • Janina Sajka (Invited Expert, The Linux Foundation)
    • +
  • Stefan Schnabel (SAP AG)
    • +
  • Lisa Seeman (Invited Expert)
    • +
  • Alexander Surkov (Mozilla Foundation)
    • +
  • Jason White (Educational Testing Service)
    • +
+
+
+
+