- From: Jan Richards <jan.richards@utoronto.ca>
- Date: Mon, 10 May 2004 16:08:09 -0400
- To: "List (WAI-AUWG)" <w3c-wai-au@w3.org>
-------- Original Message --------
Date: Mon, 10 May 2004 13:27:29 -0500
From: Barry Feigenbaum <feigenba@us.ibm.com>
To: jan.richards@utoronto.ca
CC: jutta.treviranus@utoronto.ca
Sorry these are so late.
Comments in context below prefixed with BAF
(please forgive me if I make a comment on something that is there. I
may have missed it).
Comments on guideline 3 techniques doc:
Overall very nice. Lots of good work here.
On overall formatting. I regularly print things and read them. Several
sections of this document print as too wide (text is right clipped)
especially in portrait mode. Many figures are too wide.
We should discuss the use of "can" (vs "should" or "must") on some
techniques. There are a few of them that should be close to required in
a tool (if it has that relevant aspect such as WYSIWYG).
We should also strongly suggest support prompting for localization of
accessible information
We should suggest alternates to image map input (other than the standard
user agent presentation of a list of hotspots). For example on a world
map, allow the user to enter a location in latitude/longitude or by
country name inside a separate (but related/grouped) entry form. This
alternate would always be available (unless the site supports user
preferences and it is disabled)
for 3.4.3 suggest the user marking the content with a role/flag to
insure certainty.
Comments on guideline 4 techniques doc:
I believe we need to emphasize the use of wizards and other prompted
sequences. They are one of the best ways to insure the user address all
aspects of a creation process. Any accessibility prompts need to be
on/before the first panel that has a "finish"button. Repair tools can
address pre-existing content or content edits after use of a wizard
(assuming you cannot reenter the wizard).
Should we include specific examples for the well known XML applications
(SVG, SMIL, MathML, VRML, WAP, etc)
___________________________________
Some of the following may/is already be covered in different places but
I would suggest a consolidated section (s) on this.
I think there needs to be more emphasis on high-level (semantic)
authoring vs low-level (presentation) authoring. This spans checkpoints
and especially checkpoint 3 .
Most current authoring tools generate HTML directly (ie the user works
with HTML), which is relatively low level. Tools generating HTML should
direct users to using its higher level constructs wherever possible (ex
use <CITE> vs <I>) and CSS classes on <P> or <SPAN> to indicate custom
semantics and associate any custom presentation. The tools should also
move the user always from misuse of tags such as the (infamous) use of
<TABLE> and <IMG> for layout.
I would like up to promote the use of higher level structures for
authoring and then have to tools compile/generate the HTML from this (by
a custom approach or XSLT, etc). The user should be discouraged form
changing the generated HTML. For example the IBM developerWorks site
does this for all its articles **. They have a custom XSLT-based engine
that makes HTML, PDF, ZIP, JAR, etc files for its users. The input tags
are an extended subset of HTML. Use of WYSIWYG-capable tools above
these dialects should be strongly encouraged. Having these high-level
dialects + tools makes it much easier to detects and correct content
flaws, including accessibility issues (our interest). For example, the
generation tool can fail if the <IMG> equivalent tag has no alternative
text. The tool can also notice common features (such as toolbar icons)
and provide alt text, etc. from a defined pool. It also enables other
processes, such as localization and restructuring for alternate media
form factors or user agent types.
BTW IBM did this in the past internally for all its publication up to
the mid 90's when SGML became (with IBMs help) a standard approach.
They had 3 levels of documents - Document Content Architecture (DCA) I,
II, III. DCA I was pure presentation and quite similar to HTML (full of
<I>, <B>, <BR> like stuff). DCA II was closer to XHTML 2. DCA III was
presentation agnostic and dealt in much more semantic concepts (such as
<procedure><step id=1>...</step><step id=2>...</step>...</procedure>)
that could be formatted in many was by a stylesheet (a superset of CSS
with programmable logic and user written macros) and were defined by
standard or custom tag libraries (somewhat like JSP is today) This was a
XSLT like approach.
** they are not pure yet as they still allow <i> and <b>.
_Contents_ <http://jan.atrc.utoronto.ca/public/auwg/techs.html> |
_Guideline 1_ <http://jan.atrc.utoronto.ca/public/auwg/tier1.html> |
_Guideline 2_ <http://jan.atrc.utoronto.ca/public/auwg/tier2.html> |
_Guideline 3_ <http://jan.atrc.utoronto.ca/public/auwg/tier3.html> |
Guideline 4 | _References_
<http://jan.atrc.utoronto.ca/public/auwg/refs.html>
<http://www.w3.org/>
*Implementation Techniques for
Authoring Tool Accessibility Guidelines 2.0:*
*Guideline 4: Promote and integrate accessibility solutions *
*Working Group Draft DD MMM 2004*
This version:
_http://www.w3.org/WAI/AU/2004/WD-ATAG20-20040120/tier4_
Latest version:
_http://www.w3.org/TR/ATAG20/tier4_
ATAG 1.0 Recommendation:
_http://www.w3.org/TR/ATAG10_
Editors of this chapter:
Jutta Treviranus - ATRC, University of Toronto
Jan Richards - ATRC, University of Toronto
Matt May - _W3C_ <http://www.w3.org/>
_Copyright_ <http://www.w3.org/Consortium/Legal/ipr-notice#Copyright> ©
2003 _W3C_ <http://www.w3.org/>^® (_MIT_ <http://www.lcs.mit.edu/>,
_ERCIM_ <http://www.ercim.org/>, _Keio_ <http://www.keio.ac.jp/>), All
Rights Reserved. W3C _liability_
<http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer>,
_trademark_
<http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks>,
_document use_ <http://www.w3.org/Consortium/Legal/copyright-documents>
and _software licensing_
<http://www.w3.org/Consortium/Legal/copyright-software> rules apply.
------------------------------------------------------------------------
*Integrate accessibility solutions into the overall "look and feel": *
* _Techniques for checkpoint 4.1_
<http://jan.atrc.utoronto.ca/public/auwg/tech4.html#integrate-in-workflow>:
Ensure that accessibility prompting, checking, repair functions
and documentation are integrated into the _workflow_
<http://jan.atrc.utoronto.ca/public/auwg/guidelines.html#def-workflow>
of Web Content development. [Priority 2]
* _Techniques for checkpoint 4.2_
<http://jan.atrc.utoronto.ca/public/auwg/tech4.html#check-visible-means>:
Ensure that the most accessible option for an authoring task is
given priority. [Priority 2]
* _Techniques for checkpoint 4.3_
<http://jan.atrc.utoronto.ca/public/auwg/tech4.html#check-clearly-available>:
Ensure that accessibility prompting, checking, repair functions
and documentation are always clearly available to the author
[Priority 1]
* _Techniques for checkpoint 4.4_
<http://jan.atrc.utoronto.ca/public/auwg/tech4.html#check-integrate-features>:
Ensure that accessibility prompting, checking, repair functions
and documentation are naturally integrated into the appearance and
interactive style of the tool. [Priority 3]
------------------------------------------------------------------------
*@@Editor note: As part of the techniques writing process changes are
being made to the text of success criteria and checkpoints. Once
approved, these changes need to be made back in the guideline document.@@*
*Integrate accessibility solutions into the overall "look and feel"*
*_ATAG Checkpoint 4.1_*
<http://jan.atrc.utoronto.ca/public/auwg/Overview.html#check-accessibility-everywhere1>*:
Ensure **@@that accessible authoring practices@@** are integrated into
the **_workflow_*
<http://jan.atrc.utoronto.ca/public/auwg/guidelines.html#def-workflow>*
of Web Content development. [Priority 2] *
*Techniques for "Success Criteria 1: Any mechanism that guides the
author in sequencing authoring actions (e.g. design aids, wizards,
**documentation @@GP suggestion@@**, templates) /must/ integrate
**@@accessibility@@** **_prompting_*
<http://jan.atrc.utoronto.ca/public/auwg/tech4.html#def-Prompt>*,
**_checking_*
<http://jan.atrc.utoronto.ca/public/auwg/tech4.html#def-Checking>*,
**_repair_*
<http://jan.atrc.utoronto.ca/public/auwg/tech4.html#def-Repairing>*
functions and **_documentation_*
<http://jan.atrc.utoronto.ca/public/auwg/tech4.html#def-document>*."*
WYSIWYG *Technique 4.1.1: *Specialized *@@design aids@@* can integrate
accessibility-related functionality.
*Example:* This sequence of steps of a sample interface shows how
prompting, checking, repair and documentation of accessibility issues
can be integrated into the process of creating a table. In the first
step (Figure 4.1.1(a), the author has requested that a table be
inserted. The tool prompts the author for accessibility information
(i.e. caption and summary) at the same time as the number of rows and
coluumns, etc. In this example, the tool is also assisting the author by
strating off both fields with known information (i.e. that this is the
3rd table in the document, so far). In the second step, the author has
just finished filling in the top row cells. The tools asks the author
whether this "is a row of table headers". If the author answers "Yes",
then the tool can make the repair aiutomatically. In the third step, the
author has just merged two cells in an upper header row. The tools asks
the author whether this "merged cell is a header for the column headers
below it". If the author answers "Yes", then the tool can update the
table structure accordingly. In all three examples, key terms are linked
to the help documentation.
*Figure 4.1.1(a): [**_d_*
<http://jan.atrc.utoronto.ca/public/auwg/longdescs.htm>*] (Source:
mockup by AUWG adapted from Macromedia Dreamweaver MX)
*
*Figure 4.1.1(b): [**_d_*
<http://jan.atrc.utoronto.ca/public/auwg/longdescs.htm>*] (Source:
mockup by AUWG)
*
*Figure 4.1.1(c): [**_d_*
<http://jan.atrc.utoronto.ca/public/auwg/longdescs.htm>*] (Source:
mockup by AUWG)
*
Indirect *Technique 4.1.2: *Content generation wizards can include
accessibility-related functionality.
BAF wizards etc should be a major prompting mechanism. Many samples
should be shown such as the table example above.
Screenshot #4: Wizard with prompts
ALL *Technique 4.1.3: *Documentation can highlight relevant accessible
authoring practices.
*Example: *The documentation for the INPUT element in this tool makes
use of the LABEL element in order to reinforce the routine nature of the
pairing.
*Figure 4.1.1(e): [**_d_*
<http://jan.atrc.utoronto.ca/public/auwg/longdescs.htm>*] (Source:
mockup by AUWG adapted from Microsoft Office help system)*
ALL *Technique 4.1.4: *Links to documentation should be included ... F1
link to accessiblity help...
ALL *Technique 4.1.5: *Accessibility prompts can include the following
wordings:
* ???
*_ATAG Checkpoint 4.2_*
<http://jan.atrc.utoronto.ca/public/auwg/overview.html#check-visible-means>*:
Ensure that the most accessible option for an authoring task is given
priority. [Priority 2]*
*Techniques for "Success Criteria 1: When an authoring action has
several @@more than one@@ markup implementations @@(e.g. the color of
text can be changed with presentation markup or style sheets) @@ changed
by JR@@, those markup implementation(s) that meet the requirements of
WCAG /must/ have equal or higher **_prominence_*
<http://jan.atrc.utoronto.ca/public/auwg/def-prominence>* than those
markup implementations that do not meet the @@WCAG@@ requirements."*
*Technique 4.2.1: *If there is more than one option for the author,
and one option is more accessible (@@meets WCAG@@) than another, the
more accessible option can be given _prominence_
<http://jan.atrc.utoronto.ca/public/auwg/def-prominence> and made the
default.
For HTML 4.0, examples pairings of options that are /more/ and /less/
accessible are:
*Authoring Task*
*More Accessible Option*
*Less Accessible Option*
Text styling CSS FONT element
*Technique 4.3.e: *Highlight the most accessible authoring solutions
or templates when presenting choices for the author.
*Technique 4.2.2: *Removing less accessible options altogether can
simplify the task of meeting this checkpoint.
@@???@@Different modes?
BAF: We should enumerate options: (below assume LTR order, may need to
adjust for RTL)
For a list or combobox: place the accessible items at the top of the list
For a button set: place the accessible items at the left
For menu/toolbars: highlight/emphasize the more accessible options (for
example, give them mnemonics)
*_ATAG Checkpoint 4.3_*
<http://jan.atrc.utoronto.ca/public/auwg/Overview.html#check-clearly-available>*:
Ensure that accessibility prompting, checking, repair functions and
documentation are always clearly available to the author [Priority 2]*
In some cases, several input fields are required to be completed in
order to make a single element accessible. Instead of dispersing these
prompts over multiple dialog boxes, it may be more effective to draw
them together into one group of controls with a visible tab or other
method for accessing the group (see _Figure A-5_
<http://jan.atrc.utoronto.ca/public/auwg/tech4.html#FigA5>). This can
have the additional benefit of allowing accessibility-related help
information to be provided without confusion (see "Quick Tips" in the
figure, below). The downside of placing all the accessibility related
input fields in the same area is that all of them will be neglected if
the author does not see the grouping.*
*BAF: "logical" grouping rules should take precedence. If necessary the
accessibility options can be on separate pages if easily accessed
through the many flow of the application. Typically this will not be the
case. For example, have an "description" field as a part of an image
selection dialog is both natural and appropriate.
*Techniques for "Success Criteria 1: /Continuously active processes/
(e.g. a checker that underlines errors as they occur, a checker that
runs at each save, a checker that runs every 10 minutes, etc.) that
implement functions required by checkpoints 3.1, 3.2, 3.3 and 3.7 /must/
be enabled by default."*
*Technique 4.3.1: *A scheduling interface can be provided.
Example:
*Figure 4.3.1: [**_d_*
<http://jan.atrc.utoronto.ca/public/auwg/longdescs.htm>*] (Source:
mockup by AUWG)
*
*Techniques for "Success Criteria 2: If the author chooses to disable
these /continuously active processes/, then the tool /must/ inform the
author of the consequences of their choice."*
*Technique 4.3.2: *The tool can inform the user that disabling any
continuously active process may cause problems to develop that might not
otherwise.
*Example:* This dialog box (figure @@) might be activated if the user
unchecks a "highlighting accessibility related fields" feature, as shown
in figure @@. Notice that the wording used in this example makes
refrence to the possibility that documents will be "less accessible to
many users" and that "in some jurisdictions accessibility is a legal
requirement".
*Figure 4.3.2: [**_d_*
<http://jan.atrc.utoronto.ca/public/auwg/longdescs.htm>*] (Source:
mockup by AUWG)
*
*Techniques for "Success Criteria 3: The accessibility-related
@@accessibility prompting, checking, repair and documentation@@ must
have at least the same **_prominence_*
<http://jan.atrc.utoronto.ca/public/auwg/def-prominence>* as@@
prompting, checking, repair and documentation@@ for other mandatory
information in the tool @@(e.g. prompting for file names during saves or
checking for and repairing spelling or syntax errors)."@@*
*Technique 4.3.3: *Considerations for accessibility, such as short
text label and long description attributes, can appear on the same
dialog as the source attribute, rather than buried behind an
"Advanced..." button.
BAF "can" should be "must" here.
*Technique 4.3.4: *Efficient and fast access to accessibility-related
settings with as few steps as possible needed to make any changes that
will generate accessible content.
*Technique 4.3.5: *If a single checker tool is implemented to detect
spelling errors and accessibility problems, the design can ensure equal
visibility for the accessibility checking component:
BAF spelling is an example of a verification action. this may lead one
to think its the only one (ie if no spell check, we can ignore this).
@@???@@
*Techniques for "Success Criteria 4: The accessibility-related checking
must have at least the same **_prominence_*
<http://jan.atrc.utoronto.ca/public/auwg/def-prominence>* as checking
for other high priority information in the tool (e.g. spelling or syntax
errors)." *
*Techniques for "Success Criteria 5: The accessibility-related repairing
must have at least the same **_prominence_*
<http://jan.atrc.utoronto.ca/public/auwg/def-prominence>* as repairing
for other high priority information in the tool (e.g. spelling or syntax
errors)." *
*Techniques for "Success Criteria 6: The accessibility-related
documentation must have at least the same **_prominence_*
<http://jan.atrc.utoronto.ca/public/auwg/def-prominence>* as the other
documentation in the tool." *
*_ATAG Checkpoint 4.4_*
<http://jan.atrc.utoronto.ca/public/auwg/Overview.html#check-integrate-features>*:
Ensure that accessibility prompting, checking, repair functions and
documentation are naturally integrated into the appearance and
interactive style of the tool. [Priority 3]*
*Techniques for "Success Criteria 1: The user interface for
accessibility prompting, checking, repair and documentation /must/ be
@@equivalent@@ to the user interface for comparable functions in terms
of the following characteristics: [1] visual design (measured by design
metaphors, artistic sophistication, sizes, fonts, colors), [2] operation
(measured by degree of automation, number of actions for activation),
[3] configurability (measured by number and types of features), and [4]
comprehensiveness (measured by breadth and depth of functionality
coverage)." *
*Note: use term "equivalent"*
BAF: This one tends to be the default case (one would rarely use a
different style for accessibility prompting vs other prompting) so wee
need to make this more a thing to look out for vs a conscious design
action. We should include other samples in the pattern below.
*All* *Technique 4.4.1: Accessibility-related documentation must be
similar to other documentation in the tool.*
*/Screenshot #8: Screenshot of accessibility documentaion (needs
description explaining how it is similar to non-accessibility
documentation)/*
*/Figure 4.3.2: [/**/_d_/*
<http://jan.atrc.utoronto.ca/public/auwg/longdescs.htm>*/] (Source:
mockup by AUWG adapted from Microsoft Office help system)/*
*/Work this up with classifications./*
*Code* *Technique 4.4.2(a): For code-based authoring functions an
accessibility prompting mechanism might be comparable to a code syntax
prompting mechanism.*
*/Screenshot #9: of syntax prompter; Screenshot of accessibility prompter/*
*WYSIWYG* *Technique 4.4.2(b): For WYSIWYG authoring functions, an
accessibility checking mechanism might be comparable to a spell checking
mechanism.*
* *
*/Screenshot #10: of spell checker; Screenshot of accessibility checker/*
*/Figure 4.3.X: [/**/_d_/*
<http://jan.atrc.utoronto.ca/public/auwg/longdescs.htm>*/] (Source:
mockup by AUWG )/*
*OO* *Technique 4.4.2(c): For object oriented authoring functions an
accessibility repair mechanism might be comparable to a object
manipulation operation.*
*/Screenshot #11: of user grouping controls; Screenshot of user setting
label for a form./*
*Indirect* *Technique 4.4.2(d): For indirect authoring functions, an
accessibility prompting mechanism might be comparable to a high priority
information prompting mechanism.*
*/Screenshot #12: of prompter (eg. the name of a course lecturer);
Screenshot of accessibility prompter (eg. a label for a picture)/*
*/ALL/* *Technique 4.4.5: A common toolkit can be implemented to help
design additional tool functionality modules. This might be used
internally or by third party developers to develop accessibility
plug-ins with the same look and feel as other parts of the tool. *
*/ALL/* *Technique 4.4.6: The accessibility features can be designed as
integral components of the authoring tool application, not components
that need to be separately installed or executed. *
------------------------------------------------------------------------
*Defined Term: "Prominence" [ed. will be moved to ATAG Glossary]*
The "prominence" of a control in the user interface is a heuristic
measure of the degree to which users take notice of the control when
operating the system. In these guidelines, "prominence" refers to visual
as well as keyboard-driven navigation. The factors that contribute to
"prominence" include:
* Control Size: Larger controls or controls surrounded by more
whitespace may appear to be conferred higher importance.
* Control Order: Without any other forms of organization, most
people will read interface items in a "localized" reading order
(i.e. left to right and top to bottom; right to left and top to
bottom, etc.). The higher visibility of items that occur early in
the reading order confers higher apparent importance.
* Control Grouping: Grouping input fields (e.g. in a vertical list,
etc.) can change the reading order and the related judgments of
importance.
* Advanced Options: When the properties are explicitly or implicitly
grouped into sets of basic and advanced properties, the basic
properties may gain apparent importance.
* Highlighting: Controls may be distinguished from others using
icons, color, styling, etc. When these methods are used, it is
important to ensure that that they are consistent with the overall
look and feel of the authoring tool interface (_see Checkpoint
4.4_
<http://jan.atrc.utoronto.ca/public/auwg/Overview.html#check-integrate-features>).
An additional consideration is that in order to meet ATAG
Checkpoint 7.1, the highlighting must be implemented so that it is
available through the appropriate API (MSAA, Java Accessibility
API, GNOME accessibility, etc.), allowing an author with
disabilities to access the highlighting through assistive devices .
------------------------------------------------------------------------
_Contents_ <http://jan.atrc.utoronto.ca/public/auwg/techs.html> |
_Guideline 1_ <http://jan.atrc.utoronto.ca/public/auwg/tier1.html> |
_Guideline 2_ <http://jan.atrc.utoronto.ca/public/auwg/tier2.html> |
_Guideline 3_ <http://jan.atrc.utoronto.ca/public/auwg/tier3.html> |
Guideline 4 | _References_
<http://jan.atrc.utoronto.ca/public/auwg/refs.html>
Barry A. Feigenbaum, Ph. D.
Worldwide Accessibility Center - IBM Research
www.ibm.com/able,
w3.austin.ibm.com/~snsinfo
voice 512-838-4763/tl678-4763
fax 512-838-9367/0330
cell 512-799-9182
feigenba@us.ibm.com
Mailstop 904/5F-021
11400 Burnet Rd., Austin TX 78758
W3C AUWG Representative
IBM Club Representative
Sun Certified Java Programmer, Developer & Architect
IBM Certified XML Developer; OOAD w/UML
Brainbench in C/S, WWW, e-Commerce & OO Concepts, HTML, Java 2, JSP,
EJB, XML, Smalltalk
This message sent with 100% recycled electrons
--
Jan Richards, M.Sc.
User Interface Design Specialist
Adaptive Technology Resource Centre (ATRC), University of Toronto
Email: jan.richards@utoronto.ca
Web: http://jan.atrc.utoronto.ca
Phone: 416-946-7060
Fax: 416-971-2896
Received on Monday, 10 May 2004 16:08:43 UTC