Integrate
accessibility solutions into the overall "look and feel":
- Techniques for checkpoint 4.1:
Ensure that accessibility prompting, checking, repair functions and
documentation are integrated into the workflow
of Web Content development. [Priority 2]
- Techniques for checkpoint 4.2: Ensure
that the most accessible option for an authoring task is given priority. [Priority 2]
- Techniques for checkpoint 4.3:
Ensure that accessibility prompting, checking, repair functions and
documentation are always clearly available to the author [Priority 1]
- Techniques for checkpoint 4.4:
Ensure that accessibility prompting, checking, repair functions and
documentation are naturally integrated into the appearance and interactive
style of the tool. [Priority 3]
Integrate accessibility solutions into the
overall "look and feel"
ATAG Checkpoint 4.1:
Ensure that accessibility prompting, checking, repair functions and documentation
are integrated into the 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 prompting,
checking, repair functions
and documentation."
| Indirect |
Technique 4.1.1: Content generation wizards can include accessibility-related
functionality. |
| Screenshots from a sample accessible wizard showing integration of
prompting, checking, repair functions and documentation. |
| |
@@???@@ |
ATAG Checkpoint 4.2: 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
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 than another, the more
accessible option can be given prominence
and made the default.
- Style sheets vs. deprecated
FONT element for text styling.
- @@???@@
|
| |
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. |
| |
@@???@@ |
ATAG Checkpoint 4.3: 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). 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.
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. |
| Screenshot of scheduling window with options checked. |
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. |
| Screenshot of dialog informing the user of the consequences of this
action. |
Techniques for "Success Criteria 3: The accessibility-related
@@accessibility prompting, checking, repair and documentation@@ must have at
least the same 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.
|
| |
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: |
| |
@@???@@ |
Techniques for "Success Criteria 4: The accessibility-related
checking must have at least the same 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
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
as the other documentation in the tool."
ATAG
Checkpoint 4.4: 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 similar 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)."
| All |
Technique 4.4.1: Accessibility-related documentation
must be similar to other documentation in the tool. |
Screenshot of other documentaion; screenshot of accessibility doc
/documentation_demo.png)
|
| 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 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 of spell checker; Screenshot of accessibility checker |
| OO |
Technique 4.4.2(c): For object oriented authoring functions
an accessibility repair mechanism might be comparable
to a object manipulation operation. |
| Screenshot 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 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.
|
@@
3 AXES
- 4 types of functionality in question (prompting, checking, repairing, documentation)
- 4 categories of similarity
- 4 types of tool functionality (Code-Level, WYSIWYG, Object Oriented, Indirect)
PLUS what is meant by comparable functions needs to be made clear.
@@
Defined Term: "Prominence"
[ed. maybe should 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
wll as keyboard-dreiven navigation. The factors that contribut to "prominence"
include:
- Control Size: Larger controls or controls surrounded by more whitespace
may appear to be confered 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 (eg. 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). 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 | Guideline 1 |
Guideline 2 | Guideline 3
| Guideline 4 | References