- From: Charles McCathieNevile <charles@w3.org>
- Date: Wed, 11 Oct 2000 13:35:52 -0400 (EDT)
- To: Wendy A Chisholm <wendy@w3.org>
- cc: w3c-wai-gl@w3.org
Here is what we did at the face to face meeting on SVG techniques - they are
listed accoridng to WCAG 2.
they are also available online at http://www.w3.org/2000/10/wcag2-svg-techs
This fulfils one of my action items from the meeting...
Charles McCN
[1]W3C logo [2]Web Accessibility Initiative (WAI) logo
Web Content Accessibility Guidelines 2.0
W3C Working Draft 28 September 2000
This version:
[3]http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20000928
Latest version:
[4]http://www.w3.org/WAI/GL/WCAG20
Preview version:
[5]http://www.w3.org/WAI/GL/WCAG20/wcag20-reformulation21
Editors:
Jason White, University of Melbourne
Wendy Chisholm, W3C
Gregg Vanderheiden, Trace R&D Center
Status
This document is prepared by the [6]W3C Web Content Accessibility
Guidelines Working Group (WCAG WG) to show how more generalized (less
HTML-specific) WCAG checkpoints might read. This draft is not based on
consensus of the working group nor has it gone through W3C process
thus it in no way supersedes the checkpoints in [7]WCAG 1.0.
Please refer to "[8]Issue Tracking for WCAG 2.0" for a list of open
issues related to this draft. The "[9]History of Changes to WCAG 2.0
Working Drafts" is also available.
This is a draft document and may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use W3C Working
Drafts as reference material or to cite them as other than "work in
progress". A list of current W3C Recommendations and other technical
documents can be found at [10]http://www.w3.org/TR/.
Please send comments on this document to [11]w3c-wai-gl@w3.org. The
[12]archives for this list are publicly available.
_________________________________________________________________
[13]Copyright 2000 [14]W3C ([15]MIT, [16]INRIA, [17]Keio ), All Rights
Reserved. W3C [18]liability, [19]trademark, [20]document use and
[21]software licensing rules apply. Your interactions with this site
are in accordance with our [22]public and [23]Member privacy
statements.
_________________________________________________________________
Introduction
This draft is intended for internal discussion by the working group.
Consequently, all introductory and explanatory material, together with
the technology-specific checks, have been omitted.
Guidelines and Checkpoints
Guideline 1. Design content that can be presented visually, auditorily or
tactually, according to the needs and preferences of the user.
1.1 Ensure, by providing text equivalents to auditory and graphical
presentations as necessary, that every component of a document,
web page or multimedia presentation can be rendered as text in
a standard character set.
Note: a text equivalent can take a variety of forms. It is
intended to fulfill the same function, and serve the same
purpose as the auditory or visual presentation to which it
provides an alternative. Thus, in writing a text equivalent, it
may be appropriate, in some contexts, to provide a short label
or descriptive phrase that can be substituted for the auditory
or graphical material. In other circumstances, however, a
longer explanation, description or exposition may be required.
A text equivalentmay consist of structured content or metadata,
if appropriate.
+ Use a desc and title element for all g elements
+
1.2 For any time-based multimedia presentation (e.g., a movie or
animation), synchronize the text equivalents (e.g., captions of
the audio track or descriptions of the video track) with the
presentation.
This checkpoint applies to multimedia presentations with
auditory and visual components. Where one component (either the
audio or video track) contains no significant information, a
synchronized caption or description need not be provided,
though a text equivalent, for example a description which can
be retrieved by the user in place of the multimedia
presentation, is still required (see checkpoint 1.1).
+ For animations, use multiple symbols, with relevant desc for
each, and animate the reference via a use element - see
SVG-Access
+ Use CSS-based effects, and provide stylesheets in multiple
media modes
Guideline 2. Separate content and structure from presentation and explicitly
define significant structural or semantic distinctions in markup or in a data
model.
2.1 Use markup languages properly and in accordance with
specification.
This checkpoint requires not only that document instances
comply with any formal grammar or other test of validity
provided for in the relevant markup language specification, but
also that structural elements, attributes etc., be used to
convey the meanings which have been assigned to them in the
specification.
+ Valid markup.
2.2 Use style languages, where available, to control layout and
presentation. Where practicable, provide (or link to) multiple
style sheets, each supporting a different output device.
Content and presentation can be separated because the rules
that control how content is displayed can be separated from the
markup that denotes the structure of the content.
Typically, style rules are stored separately from the content
to which they apply, in resources which are referred to in
these guidelines as style sheets. To facilitate the
presentation of Web content by a range of devices (high and
low-resolution displays, printers, speech devices, etc.), it is
advisable to associate a variety of style sheets with your Web
content.
+ Yes. CSS should be used, best to do it by classes - see
SVG-Access.
2.3 Where presentation is used to communicate distinctions of meaning
or structure within the content, also define these distinctions
in the markup or data model so that a user agent can create
alternative presentations.
The structural markup or metadata, and the presentation, may
reside in separate files or logical resources. Thus, purely
presentational versions of the content (e.g., in a graphical
format or a page description language) may be provided, so long
as there exists a version that preserves in markup the
structural and semantic distinctions implicit in the
"presentational" version. In such circumstances, content
negotiation may be used to select the version which best meets
the user's requirements.
+ Define the structure of the image in SVG, and use CSS to
provide visual styling (colour, and so on). @@
2.4 Use presentation (e.g. color or font changes) to enhance semantic
distinctions but not as the only means to understand them.
This is a corollary of the preceding checkpoint. It should not
be interpreted as discouraging the use of color or other style
properties to enhance the presentation of content. It can be
satisfied by ensuring that the distinctions conveyed by the
presentation are also reflected in the markup.
+ This seems redundant with 2.3 - at least for SVG
2.5 Use markup or a data model to provide logical structure to the
content, together with any additional semantic distinctions
that facilitate rendering of the content visually, auditorily,
or tactually.
Defining the logical structure serves two purposes:
1. Users may apply their preferred style to the content. It
allows the content to be presented effectively in a variety
of modalities on a range of output devices.
2. It provides the basis for structural navigation by the user.
In order for the content to be rendered in all three
modalities, it is necessary to capture such distinctions as
emphasis and changes in the natural language or notation in
which the text is written.
Note. Following this checkpoint, implies that the appropriate
information is provided to enable sophisticated analysis of the
content by search engines and other processing applications.
+ Structure images from components, grouping the components in
a meaningful hierarchy. Use RDF to describe more complex
relationships between components of an image - see SVG-ACCESS
and SVGX browser work.
Guideline 3. Design for ease of comprehension
Note: this guideline is applicable only in circumstances in which the
web content is intended to be presented to a human reader. A
structured data base or collection of metadata, in circumstances where
the user interface is supplied entirely by the client application,
lies outside the scope of this guideline.
3.1 Use a consistent style of presentation that will facilitate
comprehension of the content.
Consistency helps users determine the relationships between
items in the content. This ability to understand the structure
helps users navigate, orient themselves, and thus understand.
+ This is generally a requirement to have good graphic
communication.
3.2 Use color, styles, and graphics to emphasize the structure of the
document.
This will help the user
+ orient himself or herself within the document,
+ focus on the important elements of the document,
+ differentiate between a key element and the explanatory or
supplementary material.
+ Yes
3.3 Divide large blocks of information into more manageable groups
where natural and appropriate.
For example,
+ Divide user interface controls into logically organized
groups.
+ Paragraphs and sections should have clear, accurate, and
informative headers. Limiting each paragraph to one main idea
will help people process the information.
+ Use headings, paragraphs, lists etc., appropriately to
communicate relationships among items, topics or ideas.
Yes - use groupiong - see 2.5 for how
3.4 Label blocks of information to help users identify structurally
significant divisions within the content.
+ Identify important topics or subdivisions within a document
(e.g., in XHTML use the Hn elements, identify groups of user
interface controls).
+ Identify important groupings of data (e.g., label groups of
rows or columns with a header),
+ In addition to full, descriptive labels, it may also be
appropriate to provide abbreviated labels to be used when
displaying content on small displays or via speech output.
For example, an abbreviated heading for a column of data.
Use title element - see also 1.1
3.5 Place distinguishing information at the beginning of headings,
paragraphs, lists, etc.
Examples? Explanations?
+ Only really relevant for document-type presentations (but
still possible in SVG). Providing good structure and using
that to make the tree of alterntive equivalents have the most
important things at the top of the tree, with more detail
further down
3.6 Use the clearest and simplest language appropriate for a site's
content.
This checkpoint addresses the need to facilitate comprehension
of the content by all readers, especially those with cognitive
disabilities. It should not be interpreted as discouraging the
expression of complex or technical ideas. However, authors
should strive for clarity and simplicity in their writing.
+ Only really relevant for document-type presentations (but
still possible in SVG) Note that this also applies to tiles
and desc elements
3.7 Supplement text with graphic or auditory presentations where they
will facilitate comprehension of the content.
Auditory and graphical presentations can do much to improve the
comprehensibility of a web site, especially to people with
cognitive disabilities or to those who are unfamiliar with the
language in which text is written. Note that material provided
in auditory or visual forms must also be available as text (see
checkpoint 1.1).
+ Provide audio using SMIL via namespaces for descriptions /
titles. See SVG-Access
3.8 Provide an overview or summary of highly structured materials,
such as tables and groups of user interface controls.
A structure should be considered complex if it is not
immediately obvious what each piece of information is and the
reason for its position within the structure. Insinuations and
trends that are intended to be identified by analyzing the
structure, should be explicitly stated in the summary.
+ This should happen automatically as a result of 3.5, 2.5, etc
(good structure) and good 1.1
3.9 Define key terms and provide expansions for abbreviations and
acronyms, which should be identified using appropriate markup.
Note: only the first occurrence of an abbreviation or acronym
occurring in a document need be expanded. Expansion
dictionaries, for instance in metadata, may be provided as an
alternative to an expansion in the text of a document.
+ Use namespaces to mark up text elements
+ Use RDF metadata to provide the information
+ Reflect this in the text itself
3.10 Minimize content that will interfere with the users ability to
focus.
Animations and banners frequently disorient the user and
interfere with the users ability to focus from the main content
of the page. This can be improved by:
1. Restricting these items to one section of the page to help
the user retain focus.
2. For a content-filled site, providing an optional banner-free
view".
Provide an outline style - see SVG-Access
Guideline 4. Design for ease of browsing and navigation
4.1 Provide clear and consistent navigation mechanisms throughout a
document, application or site.
Such mechanisms may include logically organized groups of
hypertext links, an overview or table of contents, a site map
(with an appropriate text equivalent; see checkpoint 1.1), an
index, menu bars, etc. Navigation mechanisms should be easy to
locate and consistent. Navigation techniques for documents can
help the user skim a document. For example, in-page anchors at
each heading, grouping collections of links and allowing them
to be bypassed.
+ Use consistent presentation for identifying links. !!!
(although it can also be donme by user stylesheet
+ group blocks of links in a g element
4.2 If search functions are provided by a web site, enable different
types of searches for different skill levels and preferences.
Users with spelling disabilities or users who are learning a
new language, may have a difficult time finding information if
a search engine requires perfect spelling. Search engines might
include a spell checker, offer "best guess" alternatives,
query-by-example searches, similarity searches, etc.
4.3 Avoid methods that interfere with navigation.
Practices that can disorient a visitor include
+ automatic refresh,
+ redirection,
+ opening a new browser window,
+ frames that do not track history making the "back" button of
most browsers useless.
Guideline 5. Design user interfaces for device independence
Note: this guideline applies only where the content provides its own
user interface (for example as a form or programmatic object).
5.1 Associate an explicit label with each user interface control.
This checkpoint applies not only to individual user interface
controls but also to groups of controls.
+ Do this - @@CMN example code
5.2 Logically group user interface controls.
Note that there is an upper limit to the number of user
interface controls that should occur in a single group, refer
to checkpoint 3.x.
+ @@CMN example code
5.3 Use device-independent event handlers .
Examples?
+ See SVG-access example!! (and more code examples)
5.4 Design assistive-technology compatible user interfaces.
Use standard software conventions to control the behaviour and
activation of user interface components. Platform-specific
guidance may be available for your operating system or
application environment.
+ See User agent guidelines, and use standard declarative SVG
rather than procedural script wherever possible
Guideline 6. Design content to be compatible with the features and
capabilities of user agents, including those that only support older
technologies or standards.
6.1 Make sure that web sites which take advantage of newer
technologies continue to be usable when such technologies are
turned off or not supported.
Note: it may be desirable to provide multiple versions of the
same content in order to ensure backward compatibility. In
determining the extent to which older technologies should be
supported, content designers should bear in mind that assistive
hardware and software are often slow to adapt to technical
advances occurring in other areas, such as web-related
standards. Also, for significant groups of users, it may not be
possible to obtain the latest software or the hardware required
to operate it.
+ @@ review base level implementations (there are no older
technologies for SVG yet except for generic XML+CSS
processing - need to think about that one). THis feeds to our
requirement for establishing baseline capabilities we
expect...
6.2 Avoid causing content to blink or flicker otherwise than under the
control of the user.
Although some user agents may allow the user to suppress
blinking or flickering this is not universally the case.
Content designers should exercise special care in using these
effects.
+ Use animations - @@requirement for user agents to identify
and suppress them.
6.3 Avoid causing pages to be refreshed or updated automatically,
otherwise than in response to a user's request.
Note that this requirement can be satisfied by providing an
option to deactivate automatic updating, or to control the rate
at which it occurs. User agents may also offer control over
this effect.
+ This is tricky - animations, ... We think it is a User Agent
requirement
6.4 Where it is likely that some user agents will not support the data
format or encoding in which the content is supplied, provide
metadata, a transformation filter, a style sheet or other
mechanism to enable the content to be processed by the user
agent.
This requirement is especially relevant in circumstances where
a data format or markup language which is not widely supported,
by default, in user agent software is relied upon. Note also
the discussion of backward compatibility in checkpoint 5.1.
+ Provide style sheets for generic XML+CSS (e.g. does text get
presented, or desc, or what? @@CMN Can we write a single
default one that is normally useful)
+ Provide an XSLT to convert the text / desc into XHTML @@CMN
+ Seems redundant with 6.1 (we prefer the 6.4 version)
_________________________________________________________________
Glossary
@@need definitions
Content
Equivalent
Markup
Presentation
Semantics
References
1. http://www.w3.org/
2. http://www.w3.org/WAI
3. http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20000928.html
4. http://www.w3.org/WAI/GL/WCAG20
5. http://www.w3.org/WAI/GL/WCAG20/wcag20-reformulation21.html
6. http://www.w3.org/WAI/GL/
7. http://www.w3.org/TR/WCAG10/
8. http://www.w3.org/WAI/GL/wcag20-issues.html
9. http://www.w3.org/WAI/GL/WCAG20/change-history.html
10. http://www.w3.org/TR/
11. http://www.w3.org/2000/10/w3c-wai-gl@w3.org
12. http://lists.w3.org/Archives/Public/w3c-wai-gl/
13. http://www.w3.org/Consortium/Legal/ipr-notice.html#Copyright
14. http://www.w3.org/
15. http://www.lcs.mit.edu/
16. http://www.inria.fr/
17. http://www.keio.ac.jp/
18. http://www.w3.org/Consortium/Legal/ipr-notice.html#Legal Disclaimer
19. http://www.w3.org/Consortium/Legal/ipr-notice.html#W3C Trademarks
20. http://www.w3.org/Consortium/Legal/copyright-documents.html
21. http://www.w3.org/Consortium/Legal/copyright-software.html
22. http://www.w3.org/Consortium/Legal/privacy-statement.html#Public
23. http://www.w3.org/Consortium/Legal/privacy-statement.html#Members
Received on Wednesday, 11 October 2000 13:35:51 UTC