没有合适的资源?快使用搜索试试~ 我知道了~
无障碍丰富互联网应用(WAI-ARIA)
3星 · 超过75%的资源 需积分: 50 15 下载量 42 浏览量
2015-08-31
11:30:06
上传
评论
收藏 2.29MB PDF 举报
温馨提示
试读
101页
WAI-ARIA为了让有障碍人士无障碍的获取Web内容和使用Web应用定义了方法。WAI-ARIA可以辅助Ajax、HTML、JavaScript和其他有关主流技术和先进用户界面的开发。WAI-ARIA是由协议和格式工作组(Protocols and Formats Working Group (PFWG))工作组开发的,重点在于无障碍应用的获得难点,例如通过定义有效的方法提供辅助技术。使用WAI-ARIA,开发者可以开发出先进的Web应用,使有障碍人士无障碍的使用。
资源推荐
资源详情
资源评论
15-5-26 Accessible Rich Internet Applications (WAI-ARIA) 1.1
www.w3.org/TR/wai-aria-1.1/ 1/101
§
Accessible Rich Internet Applications (WAI-ARIA) 1.1
W3C Working Draft 14 May 2015
This version:
http://www.w3.org/TR/2015/WD-wai-aria-1.1-20150514/
Latest published version:
http://www.w3.org/TR/wai-aria-1.1/
Latest editor's draft:
http://w3c.github.io/aria/aria/aria.html
Previous version:
http://www.w3.org/TR/2014/WD-wai-aria-1.1-20141211/
Latest Recommendation:
http://www.w3.org/TR/2014/REC-wai-aria-20140320/
Editors:
Joanmarie Diggs, Igalia, S.L., jdiggs@igalia.com
James Craig, Apple Inc., jcraig@apple.com
Shane McCarron, Applied Testing and Technology, Inc., shane@aptest.com
Michael Cooper, W3C, cooper@w3.org
Copyright © 2013-2015 W3C
®
(MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.
Abstract
Accessibility of web content requires semantic information about widgets, structures, and behaviors, in order to allow
assistive technologies to convey appropriate information to persons with disabilities. This specification provides an
ontology of roles, states, and properties that define accessible user interface elements and can be used to improve the
accessibility and interoperability of web content and applications. These semantics are designed to allow an author to
properly convey user interface behaviors and structural information to assistive technologies in document-level markup.
This version adds features new since WAI-ARIA 1.0 [WAI-ARIA-10] to complete the HTML + ARIA accessibility model. It is
expected this will complement [HTML5].
This document is part of the WAI-ARIA suite described in the WAI-ARIA Overview.
Status of This Document
This section describes the status of this document at the time of its publication. Other documents may supersede this
document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C
technical reports index at http://www.w3.org/TR/.
This is a Working Draft of WAI-ARIA 1.1 by the Protocols & Formats Working Group of the Web Accessibility Initiative. This
version of ARIA 1.1 adds properties to support tables, the "aria-current" property to indicate the active item in a
container, and new roles for search boxes and switch-type checkboxes. This draft is supported by Core Accessibility API
Mappings 1.1 [[!CORE-AAM]. A history of changes to WAI-ARIA 1.1 is available in the appendix.
Feedback on any aspect of the specification is accepted. For this publication, the Protocols and Formats Working Group
particularly seeks feedback on the following questions:
Is the "aria-current" property useful and clear?
Are the table properties ("aria-colcount", "aria-colindex", "aria-colspan", "aria-rowcount", "aria-rowindex", "aria-
rowspan") useful and clear?
Are other changes to states, and properties appropriate?
To comment, send email to public-pfwg-comments@w3.org (comment archive) or file an issue in W3C Bugzilla. Comments are
requested by 19 June 2015. In-progress updates to the document may be viewed in the publicly visible editors' draft.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be
updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work
in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of
any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for
disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential
Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 1 August 2014 W3C Process Document.
Table of Contents
1. Introduction
1.1 Rich Internet Application Accessibility
1.2 Target Audience
15-5-26 Accessible Rich Internet Applications (WAI-ARIA) 1.1
www.w3.org/TR/wai-aria-1.1/ 2/101
1.3 User Agent Support
1.4 Co-Evolution of WAI-ARIA and Host Languages
1.5 Authoring Practices
1.5.1 Authoring Tools
1.5.2 Testing Practices and Tools
1.6 Assistive Technologies
2. Using WAI-ARIA
2.1 WAI-ARIA Roles
2.2 WAI-ARIA States and Properties
2.3 Managing Focus
3. Conformance
3.1 Non-interference with the Host Language
3.2 All WAI-ARIA in DOM
3.3 Assistive Technology Notifications Communicated to Web Applications
3.4 Conformance Checkers
4. Important Terms
5. The Roles Model
5.1 Relationships Between Concepts
5.1.1 Superclass Role
5.1.2 Subclass Roles
5.1.3 Related Concepts
5.1.4 Base Concept
5.2 Characteristics of Roles
5.2.1 Abstract Roles
5.2.2 Required States and Properties
5.2.3 Supported States and Properties
5.2.4 Inherited States and Properties
5.2.5 Required Owned Elements
5.2.6 Required Context Role
5.2.7 Accessible Name Calculation
5.2.7.1 Name Computation
5.2.7.2 Description Computation
5.2.7.3 Text Alternative Computation
5.2.8 Presentational Children
5.2.9 Implicit Value for Role
5.3 Categorization of Roles
5.3.1 Abstract Roles
5.3.2 Widget Roles
5.3.3 Document Structure
5.3.4 Landmark Roles
5.3.5 Live Region Roles
5.4 Definition of Roles
6. Supported States and Properties
6.1 Clarification of States versus Properties
6.2 Characteristics of States and Properties
6.2.1 Related Concepts
6.2.2 Used in Roles
6.2.3 Inherits into Roles
6.2.4 Value
6.3 Values for States and Properties
6.4 Global States and Properties
6.5 Taxonomy of WAI-ARIA States and Properties
6.5.1 Widget Attributes
6.5.2 Live Region Attributes
6.5.3 Drag-and-Drop Attributes
6.5.4 Relationship Attributes
6.6 Definitions of States and Properties (all aria-* attributes)
7. Implementation in Host Languages
7.1 Role Attribute
7.2 State and Property Attributes
7.3 Focus Navigation
7.4 Implicit WAI-ARIA Semantics
7.5 Conflicts with Host Language Semantics
7.6 State and Property Attribute Processing
A. Schemata
A.1 Roles Implementation
A.2 WAI-ARIA Attributes Module
A.3 XHTML plus WAI-ARIA DTD
A.4 SGML Open Catalog Entry for XHTML+ARIA
A.5 WAI-ARIA Attributes XML Schema Module
A.6 HTML 4.01 plus WAI-ARIA DTD
B. Mapping WAI-ARIA Value types to languages
C. Change Log
C.1 Substantive changes since the last public working draft
C.2 Other substantive changes since the WAI-ARIA 1.0 Recommendation
D. WAI-ARIA Role, State, and Property Quick Reference
E. Acknowledgments
E.1 Participants active in the PFWG at the time of publication
E.2 Other ARIA contributors, commenters, and previously active PFWG participants
E.3 Enabling funders
F. References
F.1 Normative references
15-5-26 Accessible Rich Internet Applications (WAI-ARIA) 1.1
www.w3.org/TR/wai-aria-1.1/ 3/101
§
§
F.2 Informative references
1. Introduction
This section is non-normative.
The goals of this specification include:
expanding the accessibility information that may be supplied by the author;
requiring that supporting host languages provide full keyboard support that may be implemented in a device-independent
way, for example, by telephones, handheld devices, e-book readers, and televisions;
improving the accessibility of dynamic content generated by scripts; and
providing for interoperability with assistive technologies.
WAI-ARIA is a technical specification that provides a framework to improve the accessibility and interoperability of web
content and applications. This document is primarily for developers creating custom widgets and other web application
components. Please see the WAI-ARIA Overview for links to related documents for other audiences, such as the WAI-ARIA
Primer that introduces developers to the accessibility problems that WAI-ARIA is intended to solve, the fundamental
concepts, and the technical approach of WAI-ARIA.
This draft currently handles two aspects of roles: user interface functionality and structural relationships. For more
information and use cases, see the [WAI-ARIA-PRIMER] for the use of roles in making interactive content accessible.
The role taxonomy is designed in part to support the common roles found in platform accessibility APIs. Reference to roles
found in this taxonomy by dynamic web content may be used to support interoperability with assistive technologies.
The schema to support this standard has been designed to be extensible so that custom roles can be created by extending
base roles. This allows user agents to support at least the base role, and user agents that support the custom role can
provide enhanced access. Note that much of this could be formalized in [XMLSCHEMA-2]. However, being able to define
similarities between roles, such as baseConcepts and more descriptive definitions, would not be available in XSD.
WAI-ARIA Primer [WAI-ARIA-PRIMER], a W3C Working Group Note, introduces developers to the accessibility problems that
WAI-ARIA is intended to solve, the fundamental concepts, and the technical approach of WAI-ARIA.
WAI-ARIA Authoring Practices [WAI-ARIA-PRACTICES], a planned W3C Working Group Note, describes how web content
developers can develop accessible rich internet applications using WAI-ARIA. It provides detailed advice and examples
directed primarily to web application developers, yet also useful to user agent and developers of assistive
technologies.
WAI-ARIA User Agent Implementation Guide [WAI-ARIA-IMPLEMENTATION], a planned W3C Working Group Note, describes how
browsers and other user agents should support WAI-ARIA; specifically, how to expose WAI-ARIA features to platform
accessibility APIs.
WAI-ARIA Roadmap [WAI-ARIA-ROADMAP], planned a W3C Working Group Note, defines the path to make rich web content
accessible, including steps already taken, remaining future steps, and a time line.
1.1 Rich Internet Application Accessibility
The domain of web accessibility defines how to make web content usable by persons with disabilities. Persons with certain
types of disabilities use assistive technologies (AT) to interact with content. Assistive technologies can transform the
presentation of content into a format more suitable to the user, and can allow the user to interact in different ways. For
example, the user may need to, or choose to, interact with a slider widget via arrow keys, instead of dragging and dropping
with a mouse. In order to accomplish this effectively, the software needs to understand the semantics of the content.
Semantics is the science of meaning; in this case, used to assign roles, states, and properties that apply to user
interface and content elements as a human would understand. For instance, if a paragraph is semantically identified as
such, assistive technologies can interact with it as a unit separable from the rest of the content, knowing the exact
boundaries of that paragraph. An adjustable range slider or collapsible list (a.k.a. a tree widget) are more complex
examples, in which various parts of the widget have semantics that need to be properly identified for assistive
technologies to support effective interaction.
New technologies often overlook semantics required for accessibility, and new authoring practices often misuse the intended
semantics of those technologies. Elements that have one defined meaning in the language are used with a different meaning
intended to be understood by the user.
For example, web application developers create collapsible tree widgets in HTML using CSS and JavaScript even though HTML
has no semantic tree element. To a non-disabled user, it may look and act like a collapsible tree widget, but without
appropriate semantics, the tree widget may not be perceivable to, or operable by, a person with a disability because
assistive technologies may not recognize the role.
The incorporation of WAI-ARIA is a way for an author to provide proper semantics for custom widgets to make these widgets
accessible, usable, and interoperable with assistive technologies. This specification identifies the types of widgets and
structures that are commonly recognized by accessibility products, by providing an ontology of corresponding roles that can
be attached to content. This allows elements with a given role to be understood as a particular widget or structural type
regardless of any semantic inherited from the implementing host language. Roles are a common property of platform
accessibility APIs which assistive technologies use to provide the user with effective presentation and interaction.
This role taxonomy includes interaction widgets and elements denoting document structure. The role taxonomy describes
inheritance and details the attributes each role supports. Information about mapping of roles to accessibility APIs is
provided by the WAI-ARIA User Agent Implementation Guide [WAI-ARIA-IMPLEMENTATION].
Roles are element types and will not change with time or user actions. Role information is used by assistive technologies,
through interaction with the user agent, to provide normal processing of the specified element type.
States and properties are used to declare important attributes of an element that affect and describe interaction. They
enable the user agent and operating system to properly handle the element even when the attributes are dynamically changed
by client-side scripts. For example, alternative input and output technology, such as screen readers and speech dictation
software, need to be able to recognize and effectively manipulated and communicate various interaction states (e.g.,
15-5-26 Accessible Rich Internet Applications (WAI-ARIA) 1.1
www.w3.org/TR/wai-aria-1.1/ 4/101
§
disabled, checked) to the user.
While it is possible for assistive technologies to access these properties directly through the Document Object Model [DOM-
Level-2-Core], the preferred mechanism is for the user agent to map the states and properties to the accessibility API of
the operating system. See the WAI-ARIA User Agent Implementation Guide [WAI-ARIA-IMPLEMENTATION] for details.
Figure 1.0 illustrates the relationship between user agents (e.g., browsers), accessibility APIs, and assistive
technologies. It describes the "contract" provided by the user agent to assistive technologies, which includes typical
accessibility information found in the accessibility API for many of our accessible platforms for GUIs (role, state,
selection, event notification, relationship information, and descriptions). The DOM, usually HTML, acts as the data model
and view in a typical model-view-controller relationship, and JavaScript acts as the controller by manipulating the style
and content of the displayed data. The user agent conveys relevant information to the operating system's accessibility API,
which can be used by any assistive technologies, such as screen readers.
Figure 1: The contract model with accessibility APIs
For more information see the WAI-ARIA Primer [WAI-ARIA-PRIMER] for the use of roles in making interactive content
accessible.
In addition to the prose documentation, the role taxonomy is provided in Web Ontology Language (OWL) [OWL-FEATURES], which
is expressed in Resource Description Framework (RDF) [RDF-CONCEPTS]. Tools can use these to validate the implementation of
roles in a given content document. For example, instances of some roles are expected to be children of a specific parent
role. Also, some roles may support a specific state or property that another role does not support.
Users of alternate input devices need keyboard accessible content. The new semantics, when combined with the recommended
keyboard interactions provided in WAI-ARIA Authoring Practices [WAI-ARIA-PRACTICES], will allow alternate input solutions
to facilitate command and control via an alternate input solution.
WAI-ARIA introduces navigational landmarks through its taxonomy and the XHTML role landmarks, which can help persons with
dexterity and vision impairments by providing for improved keyboard navigation. WAI-ARIA may also be used to assist persons
with cognitive learning disabilities. The additional semantics allow authors to restructure and substitute alternative
content as needed.
Assistive technologies need the ability to support alternative inputs by getting and setting the current value of widget
states and properties. Assistive technologies also need to determine what objects are selected and manage widgets that
allow multiple selections, such as list boxes and grids.
Speech-based command and control systems can benefit from WAI-ARIA semantics like the role attribute to assist in conveying
audio information to the user. For example, by determining that an element has a role of menuitem each containing text
content representing a different flavor, a speech system might state to the user that, "Select one of three choices:
chocolate, strawberry, or vanilla."
WAI-ARIA is intended to be used as a supplement for native language semantics, not a replacement. When the host language
provides a feature that provides equivalent accessibility to the WAI-ARIA feature, use the host language feature. WAI-ARIA
should only be used in cases where the host language lacks the needed role, state, and property indicators. Use a host
language feature that is as similar as possible to the WAI-ARIA feature, then refine the meaning by adding WAI-ARIA. For
instance, a multi-selectable grid could be implemented as a table, and then WAI-ARIA used to clarify that it is an
interactive grid, not just a static data table. This allows for the best possible fallback for user agents that do not
support WAI-ARIA and preserves the integrity of the host language semantics.
1.2 Target Audience
This specification defines the basic model for WAI-ARIA, including roles, states, properties, and values. It impacts
NOTE
The use of RDF/OWL as a formal representation of roles may be used to support future extensibility. Standard RDF/OWL
mechanisms can be used to define new roles that inherit from the roles defined in this specification. The mechanism to
define and use role extensions in an interoperable manner, however, is not defined by this specification. A future
version of WAI-ARIA is expected to define how to extend roles.
15-5-26 Accessible Rich Internet Applications (WAI-ARIA) 1.1
www.w3.org/TR/wai-aria-1.1/ 5/101
§
§
§
§
several audiences:
User agents that process content containing WAI-ARIA features;
Assistive technologies that present content in special ways to user with disabilities;
Authors who create content;
Authoring tools that help authors create conforming content; and
Conformance checkers that verify appropriate use of WAI-ARIA.
Each conformance requirement indicates the audience to which it applies.
Although this specification is applicable to the above audiences, it is not specifically targeted to, nor is it intended to
be the sole source of information for, any of these audiences. The following documents provide important supporting
information:
WAI-ARIA Authoring Practices addresses authoring recommendations, and is also of interest to developers of authoring
tools and conformance checkers.
WAI-ARIA User Agent Implementation Guide addresses developers of user agents and assistive technologies.
1.3 User Agent Support
WAI-ARIA relies on user agent support for its features in two ways:
Mainstream user agents use WAI-ARIA to alter how host language features are exposed to accessibility APIs in order to
improve accessibility. The mechanism for this is defined in the WAI-ARIA User Agent Implementation Guide [WAI-ARIA-
IMPLEMENTATION].
Assistive technologies use the enhanced information available in an accessibility API, or uses the WAI-ARIA markup
directly via the DOM, to convey semantic and interaction information to the user.
Aside from using WAI-ARIA markup to improve what is exposed to accessibility APIs, user agents behave as they would
natively. Assistive technologies react to the extra information in the accessibility API as they already do for the same
information on non-web content. User agents that are not assistive technologies, however, need do nothing beyond providing
appropriate updates to the accessibility API.
The WAI-ARIA specification neither requires nor forbids user agents from enhancing native presentation and interaction
behaviors on the basis of WAI-ARIA markup. Mainstream user agents might expose WAI-ARIA navigational landmarks (for
example, as a dialog box or through a keyboard command) with the intention to facilitate navigation for all users. User
agents are encouraged to maximize their usefulness to users, including users without disabilities.
WAI-ARIA is intended to provide missing semantics so that the intent of the author may be conveyed to assistive
technologies. Generally, authors using WAI-ARIA will provide the appropriate presentation and interaction features. Over
time, host languages may add WAI-ARIA equivalents, such as new form controls, that are implemented as standard accessible
user interface controls by the user agent. This allows authors to use them instead of custom WAI-ARIA enabled user
interface components. In this case the user agent would support the native host language feature. Developers of host
languages that implement WAI-ARIA are advised to continue supporting WAI-ARIA semantics when they do not adversely conflict
with implicit host language semantics, as WAI-ARIA semantics more clearly reflect the intent of the author if the host
language features are inadequate to meet the author's needs.
1.4 Co-Evolution of WAI-ARIA and Host Languages
WAI-ARIA is intended to augment semantics in supporting languages like [HTML5] and [SVG2], 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's better to use an heading role on a div element.
It is expected that, over time, host languages will evolve to provide semantics for objects that currently can only be
declared with WAI-ARIA. 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 WAI-ARIA for that feature. Legacy content may continue to use WAI-ARIA, however,
so the need for user agents to support WAI-ARIA remains.
While specific features of WAI-ARIA may lose importance over time, the general possibility of WAI-ARIA to add semantics to
web pages is expected to be a persistent need. Host languages may not implement all the semantics WAI-ARIA provides, and
various host languages may implement different subsets of the features. New types of objects are continually being
developed, and one goal of WAI-ARIA is to provide a way to make such objects accessible, because web authoring practices
often advance faster than host language standards. In this way, WAI-ARIA 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; XForms
provides semantics for form controls and does not provide wider user interface features. Host languages such as these
might, by design, not provide native semantics that map to WAI-ARIA features. In these cases, WAI-ARIA could be adopted as
a long-term approach to add semantic information to user interface components.
1.5 Authoring Practices
1.5.1 Authoring Tools
Many of the requirements in the definitions of WAI-ARIA roles, state, and properties can be checked automatically during
剩余100页未读,继续阅读
资源评论
- 第一大势2018-01-30没有插件吗
csdn_csdn__AI
- 粉丝: 2244
- 资源: 117
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
- windows 64位 libiec61850.dll release版本
- 光伏并网发电设计常用软件与计算表.zip
- PY104.py
- windows 64位 libiec61850.dll
- 机械设计新能源元器件剪切折弯设备(sw15可编辑+工程图+bom)非常好的设计图纸100%好用.zip
- TheMonsieurTea.mp3
- winrar安装包(windows x64系统,用于解压rar文件,python用此软件批量解压缩文件)
- 易语言源码珍宝谜局益智类游戏(易语言2007年大赛一等奖)
- Release of 13.2.0-rt-v11-rev0
- Python音乐下载器实现语音在线点歌源码
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功