Revised 27 August 2001
Authors: Graham Oliver, Charles McCathieNevile
This is a partial evaluation of Lotus Domino 5.02a and how it conforms to the Authoring Tool Accessibility Guidelines. The evaluation was done against the document http://www.w3.org/WAI/AU/WD-ATAG10-TECHS-20010319/ which includes the checkpoint text of The Authoring Tool Accessibility Guidelines 1.0 Recommendation of 3 Feburary 2000 by Graham Oliver, with some additional work by Charles McCathieNevile. This work has not been endorsed by anyone but the two authors, who do not guarantee it is complete or correct (it may contain errors and is definitely not complete).
There are notes in here where the authors are not sure about how to interpret something. It is hoped that this will serve as useful input for the Authoring Tool Accessibility Guidelines working group to modify the techniques document and clarify issues.
This document has been provided to Lotus Inc for their comments. Any comments received in future may be included by the authors in a future revision, along with further review results.
This document may be updated at any time, or obsoleted by a review of a more recent version of the software.
Lotus Domino is assumed to fall into the following two categories :-
Markup Editing Tools:
Tools that assist authors to produce markup documents. These include text-based and WYSIWYG markup editors for HTML, XHTML, SMIL, etc. and word processors that save as markup formats.and
Content Management Tools:
Tools that assist authors to create and organize specific types of Web content without the author having control over the markup or programming implementation. Good examples include courseware in which the author is prompted to enter various information which is then displayed in a format determined by the tool. Note: If the tool allows the author to control the markup that is actaully used to implement the higher-order content, then that functionality would be considered to be a Markup Editing Tool.Where the WCAG Guidelines are referenced only Priority 1 Guidelines are considered.
Ensure that all structural features of the
supported languages are available within the tool. [Required] @@
Yes, if you mean can you write any sort of markup that you want.
Allow the author to directly edit the source
markup. (Suggested)
Partially
Example (Successful Editing of Source markup)
Basic WYSIWYG table
Creating a basic WYSIWYG table in Domino, results in the following HTML.
<HTML>
<!-- Lotus-Domino (Release 5.0.2a (Intl) -
23 November 1999 on Windows NT/Intel) -->
<HEAD>
</HEAD>
<BODY TEXT="000000"
BGCOLOR="FFFFFF">
<FORM>
<TABLE BORDER=1>
<TR VALIGN=top><TD
WIDTH="251"><B>Country</B></TD><TD
WIDTH="251"><B>Capital</B></TD></TR>
<TR VALIGN=top><TD WIDTH="251">New
Zealand</TD><TD
WIDTH="251">Wellington</TD></TR>
<TR VALIGN=top><TD
WIDTH="251">Australia</TD><TD
WIDTH="251">Canberra</TD></TR>
</TABLE>
</FORM>
</BODY>
</HTML>
Note the Domino renders all of its HTML in upper case, which is not be very XHTML friendly. However, as I am using the convention of adding all markup in lower case it allows the added markup to be spotted more easily.
Basic WYSIWYG table + Added Markup
Using the following dialog box, I am able to add table and cell tags
Which results in the following html
<HTML>
<!--
Lotus-Domino (Release 5.0.2a (Intl) - 23 November 1999 on Windows NT/Intel)
-->
<HEAD>
</HEAD>
<BODY TEXT="000000" BGCOLOR="FFFFFF">
<FORM>
<TABLE
ID="inserted_id" CLASS="inserted_class" STYLE="inserted_style"
TITLE="inserted_title" cellpadding="2" cellspacing="0"
BORDER=1>
<TR
VALIGN=top><TD
WIDTH="251"><B>Country</B></TD><TD
WIDTH="251"><B>Capital</B></TD></TR>
<TR
VALIGN=top><TD WIDTH="251">New Zealand</TD><TD
ID="inserted_id_cell" CLASS="inserted_class_cell" STYLE="inserted_style_cell"
TITLE="inserted_title_cell" align="right"
WIDTH="251">Wellington</TD></TR>
<TR
VALIGN=top><TD WIDTH="251">Australia</TD><TD
WIDTH="251">Canberra</TD></TR>
</TABLE>
</FORM>
</BODY>
</HTML>Example (Unsuccessful Editing of Source markup)
Using the above example it is not possible (for example) to influence the rendering of the <TD> tag in the first row of the table. So they cannot be marked up as <TH> tags.
Conclusion
Domino could allow more editing of Source markup and in the case of <TH> tags makes the product arguably non-compliant with the section 508 requirement that 'Row and column headers shall be identified for data tables'.CMN: I wuld argue that it does fail the checkpoint, although it does meet the requirement for some cases.
When an extended (super-set) or simplified
(sub-set) markup language is supported, ensure that the accessibility features
in the base language are still available. (Suggested)Don't understand this one CMN If the
language it uses is smaller or bigger than HTML, but is derived from it, make
sure that it supports all the accesssibliity features. For the HTML example,
that includes longdesc (don't know) and th (which it
doesn't)
Ensure that the tool
preserves all the elements that are defined in the relevant specification(s)
even if it is unable to render them in a publishing view or preview
mode.[Required] @@
With authoring nothing will be thrown away.
Domino also has an 'Import Service' (DIS) that allows html pages to be 'sucked into' Domino , see
http://www.notes.net/today.nsf/f01245ebfc115aaf8525661a006b86b9/dc30cd765ea86881852568f10060b96b?OpenDocument(Note that the latest version of this tool is 2.1)
No evaluation of this process has been carried out for its impact on the markup.
I don't know how DIS will deal with unrecognised markup
When transforming a table
to a list or list of lists, ensure that table headings are transformed into
headings and that summary or caption information is retained as rendered
content. [Required] @@
Not relevant as far as I am aware because I don't understand under what circumstances a table would be being transformed. CMN for example, if it gets a table with th elements, does it keep them? (authoring). I don't know if it allows you to do transforms from one type of thing (e.g. a list) to another (e.g a table) or not.
When converting
documents, allow authors to edit conversion templates to specify the way
presentation conventions should be converted into structural
markup.(Suggested)
Don't believe DIS allows this.
When importing images
with associated descriptions into a markup document, make the descriptions
available through appropriate markup. 
Would need to test this
I believe that DIS would keep text as text.
When converting from a
word-processor format to markup, ensure that headings and list items are
transformed into appropriate structural markup (appropriate level of heading
or type of list, etc.).
n/a CMN I thought that it could interpret RTF / Word. If it converts a Word Heading or list into an HTML one it does this - if it converts it to formatted text it doesn't.
Ensure that changes to a
document's graphical layout do not reduce readability when rendered serially.
Some desktop publishing software allow the author to view the linearized
reading order. (Suggested)
I don't understand this one. CMN If moving text around (I guess in a template) means that it doesn't move around in the HTML source it generates then it fails. Publisher fails. I suspect Lotus doesn't.
Don't know what DIS does.
CMN This only applies to markup the tool makes itself - for example you do some layout in genrating a template and it does it in some horrid way like Publisher does.
Ensure that any
markup generated automatically by the tool conforms to the WCAG10
guidelines.
(WCAG 1.1,
P1) Provide a text equivalent* for every generated non-text element. This
includes:
The author can add alt text using the following dialog box
As for images
Domino does not automatically generate image maps, it’s a manual coding exercise.
As for images
As for images (but note that the alt text appears to be marked as optional)
Recommendation
Remove the word 'Optional' from this dialog box
Manual coding exercise
As for images
Manual coding exercise
Can't be done 'naturally' using Domino, only methodology would end up with a process where equivalent text would be added as for images.
As for images
As for images
Domino doesn't provide the ability to provide text equivalents of any of the above (as far as I am aware).
Remark *
They seem like a separate category to me (certainly in Domino terms) and possibly in 'tool maturity terms'.
(WCAG
1.2, P1) Provide redundant text links* for each active region of
a generated server-side image map.
Manual coding exercise
(WCAG
1.3, P1) Until user agents can automatically read aloud the text
equivalent of a visual track, provide an auditory description* of the
important information of the visual track of a generated multimedia
presentation.
Not relevant (see Remark * above)
(WCAG
1.4, P1) For tools that generate time-based multimedia
presentations (e.g., a movie or animation), ensure synchronized equivalent
alternatives* are provided. (e.g., captions or auditory descriptions of
the visual track)
Not relevant (see Remark * above)
(WCAG
2.1, P1) Ensure that all generated information conveyed with
color is also available without color.
Manual coding exercise
(WCAG
4.1, P1) Clearly identify changes in the natural language of
generated text.
Manual coding exercise
(WCAG
5.1, P1) For generated data tables, identify row and column
headers.
This has been dealt with above (see the 'Edit Source Markup' section)
Domino appears to be in breach of this guideline.
(WCAG
5.2, P1) For generated data tables that have two or more logical
levels of row or column headers, use markup to associate data cells and
header cells.
Similar to the above issue
WCAG
6.1, P1) Organize generated documents so they may be read without
style sheets.
Manual coding and testing exercise
(WCAG
6.2, P1) Ensure that equivalents* for generated dynamic content
are updated when the dynamic content changes.
This is pretty much covered under the WCAG 1.1 section above
(WCAG
6.3, P1) Ensure that generated pages are usable when scripts,
applets, or other programmatic objects are turned off or not supported. If
this is not possible, provide equivalent information* on an alternative
accessible page.
Manual coding exercise
(WCAG
7.1, P1) Until user agents allow users to control flickering,
avoid generating markup that causes the screen to flicker.
Manual coding exercise
(WCAG
8.1, Important and not elsewhere: P1, Otherwise: P2) Make
generated programmatic elements such as scripts and applets directly
accessible or compatible with assistive technologies.
This is not really Domino's job (I would say), it just picks up what has been produced by another tool.
(WCAG
9.1, P1) Generate client-side image maps instead of server-side
image maps except where the regions cannot be defined with an available
geometric shape.
Manual coding exercise
(WCAG
11.4, P1) If, after best efforts, a generated alternative page is
necessary, ensure that it includes equivalent information (or
functionality), and is updated as often as the inaccessible (original)
page.
Manual coding exercise
(WCAG
12.1, P1) Title* each generated frame to facilitate frame
identification and navigation.
Covered above, you can do this with Domino
(WCAG
14.1, P1) Generate the clearest and simplest language appropriate
for a site's content.
Manual exercise, but Domino has a spell checker built into the Designer.
Terminology Clarification
Domino uses different terminology to a lot of other web development tools.
A 'Template' from a Domino perspective ('Domino Template') has no natural equivalent in the world of web development. It is in fact a database that acts as a repository for commonly used design elements.
A 'Template' ('Web Template') in the world of web development has its closest equivalent in a 'Domino Form'.
For tools that allow
author's to create their own templates, advise the author that templates
should be held to a high accessibility standard, since they will be repeatedly
re-used. Help the author reach this goal by making an accessibility check
mandatory before saving as a template. (Suggested)
Domino does allow authors to create their own templates (Domino Form). No accessibility check is done before saving.
Ensure that any
template provided by the tool conforms to the WCAG10 guidelines. Because this
ATAG checkpoint has a relative priority, it is the priority of the relevant
WCAG checkpoints that determines the level of conformance of the tool to the
ATAG checkpoint *Note on Equivalent Alternatives: The
equivalent alternatives themselves may not appear in the template unless the
function of the non-text element is known with certainty (see ATAG
3.4)):
Domino provides a large number of standard 'Domino Templates' which contain large numbers of 'Domino Forms' ('Web Templates').
None of them will have been created with accessibility in mind (I would imagine) and the process of going through them to identify where they produce inaccessible markup is a big one.
Could start with the most commonly used, mail and discussion?
When creating documents or markup languages, make full use of W3C Recommendations (see WCAG 11.1,
P2). For example, when creating mathematical content for the
Web use MathML [MATHML] rather than
another markup language. Use applicable HTML 4 [HTML4] structures.[Required] @@
Domino doesn't do this well.
There appears to be little regard for the W3C standards when Domino renders content to the web.
A Few Examples
When creating a 'Domino Page', Domino will add the <FORM> element for no apparent reason. This causes a failure under validation because the resulting page doesn't have an associated action (It doesn't need one!!!)
The <HEAD> element is allowed to be empty, no title is required.
It is relatively easy to create a duplicate 'attribute' such as
<BODY TEXT="000000" BGCOLOR="FFFFFF" TEXT="FFFFFF">
Do not publish
Web content in markup languages that do not allow for equivalent
alternative information to be included for media-specific presentations
(such as images or video, sound, etc). Where this cannot be avoided,
make the information directly available from the content generated. For
example, convert the text equivalent of an image to a caption for the
image, or provide a "base" page that includes links to alternative
versions of content.[Required] @@
I don't really understand this one. CMN I suspect it doesn't apply - if Domino produces HTML then it is a question of whether it can generate longdesc, alt, etc. Depends on what it allows you to add somehow... (but it will fail checkpoints 5.1 and 5.2 I guess)
When inserting
objects such as spreadsheets or word processor documents, offer the
option of providing a Web-formatted version. For example, a spreadsheet
or a word processor document in a proprietary format could also be
published as an HTML document. Tools that dynamically generate Web
content may use HTTP content negotiation to facilitate this.[Required]
@@
I don't really understand this one. CMN Hmm, maybe I don't either. Let's throw it to the group.
A modular
design that allows for the inclusion of languages will permit tools to
have a language "available" later in their development cycle, or may
allow tools to use languages which are not specified at the time of
development. Specifications that become W3C Recommendations after an
authoring tool's development cycles permit input are not considered
"available" in time. (Suggested)
This is under the hood
Ensure that the
markup produced by the tool, in any of its supported languages, is
valid.[Required] @@
Not done
Publish proprietary
language specifications or DTDs on the Web, to allow documents to be
validated.[Required] @@
I don't fully understand this one, because I don't know why I would publish a DTD on the web.
The use of DTD's is not usual in Domino, but can be done. CMN Presumably if you use a different DTD you don't generate it in Domino, so this would not apply.
Use namespaces and
schemas to make documents that can be automatically transformed to a
known markup language.[Required] @@
If I understand this correctly, the namespaces and schemas are part of the DTD, so the same answer as above applies.
To minimally meet this checkpoint, a tool must somehow inform the
author that the markup produced does not conform to W3C specifications.
This might be done with a statement on the saving dialog or with an
alert that is displayed following a save.(Suggested)
Not done
Invalid markup
can be highlighted through the use of style sheets.(Suggested)
Not done
If the tool
produces inaccessible markup, whether it is valid or not, see ATAG 4.1 for checking
techniques.(Suggested)
Not done
Provide a preview
mode that uses alternative content. Although this can give authors a
clear understanding of some problems very easily, it should be made
clear that there are many ways in which a page may be presented
(aurally, text-only, text with pictures separately, on a small screen,
on a large screen, etc.). A view that renders the document as it might
appear without technologies such as style sheets and images enabled, or
the ability to turn those features off and on in the editing view, will
also give an author some idea of whether a document's logical order has
been correctly preserved, whether alternative text is appropriate,
etc.(Suggested)
Not done
Prompt the
author to provide equivalent alternative information (e.g., captions,
auditory descriptions, and collated text transcripts for video). Because
this ATAG checkpoint has a relative priority, it is the priority of the
relevant WCAG checkpoints that determines the level of conformance of
the tool to the ATAG checkpoint:
Domino doesn't do prompting
ATAG 3.2 Help the
author create structured content and separate information from its
presentation. [Relative Priority] (Checkpoint
3.2)Support
author's of DTD's or Schemas to specify explicit structure. For example,
encourage nesting where appropriate.Help the author
create structured content and separate information from its
presentation. Because this ATAG checkpoint has a relative priority, it
is the priority of the relevant WCAG checkpoints that determines the
level of conformance of the tool to the ATAG checkpoint:
Not done
(WCAG
2.1, P1) Ensure that all information conveyed with color is
also available without color.
Not done
(WCAG
4.1, P1) Clearly identify changes in the natural language of a
document's text and any text equivalents (e.g., captions).
Not done
(WCAG
5.1, P1) For data tables, identify row and column headers.
Not done
(WCAG
5.2, P1) For data tables that have two or more logical levels of
row or column headers, use markup to associate data cells and header
cells.
Not done
(WCAG 6.1, P1)
Organize documents so they may be read without style sheets.
Not done
(WCAG
6.3, P1) Ensure that pages are usable when scripts, applets, or
other programmatic objects are turned off or not supported. If this is not
possible, provide equivalent information on an alternative accessible
page.
Not done
Not done
(WCAG
7.1, P1) Until user agents allow users to control flickering,
avoid causing the screen to flicker.
Not done, it’s a manual exercise
(WCAG
9.1, P1) Use client-side image maps instead of server-side image
maps except where the regions cannot be defined with an available
geometric shape.
Not done, it’s a manual exercise
(WCAG
12.1, P1) Title each frame to facilitate frame identification and
navigation.
Not done
(WCAG
14.1, P1) Use the clearest and simplest language appropriate for
a site's content.
Not done
Not done
Not done
Not done
Note: Including pre-written descriptions for all multimedia files (e.g., clip-art) packaged with the tool will save authors time and effort, cause a significant number of professionally written descriptions to circulate on the Web, provide authors with convenient models to emulate when they write their own descriptions, and show authors the importance of description writing.
Refer also to checkpoint 3.5.Use formats that allow
for accessible annotation to be included in the files, such as SMIL, PNG, and
SVG.[Required] @@
n/a
Provide long
descriptions, and associated text files with appropriate
text equivalent in clip-art
collections.[Required] @@
n/a
Provide video description
files with prepackaged video.[Required] @@
n/a
Provide text caption
files for prepackaged audio, or video with auditory track(s).[Required]
@@
n/a
Answer
In Domino views the 'twistie' has automatically generated alt text of '+'.
This is not particularly intuitive for screen reader user. Although you could argue it's about as intuitive as the twistie <grin>. CMN yes...
If the author has not
specified alternative text for an
IMG, or specified that none is required, default to having
no"alt" attribute, so that an accessibility problem will be
noted.Refer also to checkpoint
4.1.[Required] @@
Default behaviour
Human-authored equivalent
alternatives may be available for an object (for example, through
checkpoint 3.5 and/orcheckpoint 3.3). It is appropriate for the
tool to offer these to the author as defaults.(Suggested)
Not available
Items used throughout a
Website, such as graphical navigation bars, should have standard alternative
information. However the author should be prompted to edit or approve this the
first time it is used in a site, and when the destination of the links is
changed by the author.(Suggested)
No prompts but Domino does allow resuse of things like graphical navigation bars.
Where an object has
already been used in a document, the tool should offer the alternative content
that was supplied for the first or most recent use as a
default.(Suggested)
The same as above
Note:
This checkpoint is priority 3, so it does not have a critical effect on an authoring tool's likelihood of producing accessible mark-up. However, implementing this checkpoint has the potential to simultaneously satisfy several higher priority checkpoints (ATAG 3.1, ATAG 3.2, and ATAG 3.4) and dramatically improve the usability of an authoring tool.Maintain a database
registry that associates object identity information with alternative
information. Whenever an object is used and an equivalent alternative is
collected (as per
checkpoint 3.1) add the object (or
identifying information) and the alternative information to the database. In
the case of atext equivalent, the
alternate information may be stored in the document source. For more
substantial information (such as video captions or audio descriptions), the
information may be stored externally and linked from the document source.
Allow different alternative information to be associated with a single
object.(Suggested)
Not done.
Alternatives are added when the image is introduced into the design element ('Domino Form' or 'Domino Page'). However, given the current Domino architecture it may be possible to add 'Default Alternative Information' in the Image Resources area, this is (at least partly) what is asked for above
If such a database is
maintained, the pre-written descriptions can be presented to the author as
default text in the appropriate field, whenever one of the associated files is
inserted into the author's document. This satisfies ATAG 3.4 because the
equivalent alternatives are not automatically generated and they are only
reused with author confirmation.(Suggested)
See above.
If no previous
association is found, the field should be left empty (i.e., no purely
rule-generated alternative information should be used). Note:
The term "default" implies that the alternative information is offered for the
author's approval. The term does not imply that the default alternative
information is automatically placed without the author's approval. Such
automatic placement may only occur when in situations where the function of
the object is known with certainty, per
checkpoint 3.4. Such a situation might
arise in the case of a "navigation bar builder" that places a navigation bar
at the bottom of every page on a site. In this case, it would be appropriate
to use the same "alt"-text automatically for every instance of a particular
image (with the same target) on every page.(Suggested)
n/a
The pre-written
alternative information provided for all packaged multimedia files (per
checkpoint 3.3) should be included in
the database. This would allow the alternative information to be automatically
retrieved whenever the author selected one of the packaged objects for
insertion. An important benefit of the system would be the ease of adding a
keyword search capability that would allow efficient location of multimedia
based on its alternative information.(Suggested)
Not done and I don't think is relevant.
Note:
Accessibility problems should be detected automatically where possible. Where this is not possible, the tool may need to prompt the author to make decisions or to manually check for certain types of problems. In the section below, the evaluation (ATAG 4.1) and repair (ATAG 4.2) techniques for each WCAG checkpoint have been grouped together.Answer
Not done
Where the tools cannot test for
accessibility errors, provide the author with the necessary information,
wizards, etc. to check for themselves.(Suggested)
Answer
Not done
At a minimum, provide context-sensitive help
with the accessibility checking required by
checkpoint 4.1
.
Answer
Not done
Where there are site-wide errors, to make
correction more efficient, allow the author to make site-wide changes or
corrections. For example, this may be appropriate for a common error in
markup, but may not be appropriate in providing a text equivalent that is
appropriate for one use of an image but completely inappropriate for the other
uses of the image on the same site (or even the same page).(Suggested)
The nature of Domino, allows this to be done to a certain extent, using Domino Forms or SubForms and Image Resources.
Assist authors in ways that are consistent
with the look and feel of the authoring tool (See ATAG 5.1).(Suggested)
n/a as there is no assistance
Allow authors to control both the nature and
timing of the correction process.(Suggested)
As above
Provide a mechanism for authors to navigate
sequentially among uncorrected accessibility errors (See
ATAG 7.4).(Suggested)
Not done
Note:
The author may have included or imported markup that enhances accessibility but is not recognized by the tool.If possible, preserve all unrecognized
markup, since it might be related to accessibility (See ATAG
1.2).[Required]
OK
If changes to markup that is not recognized
by the tool are necessary for the tool to further process the document (for
example, a tool that requires valid markup when a document is opened), inform
the author.[Required] @@
not applicable
Provide options for the author to confirm or
override removal of markup on a change-by-change basis or as a batch
process.(Suggested)
Not done
Provide a summary of all automated
structural changes that may affect accessibility.(Suggested)
Not done
Do not change the DTD without notifying the
author.(Suggested)
Not done, there are no DTDs
Provide a list of all accessibility errors found
in a Web page.[Required] @@Answer
Not done
Provide a summary of accessibility problems
remaining by type and/or by number.(Suggested)
Not done
Answer
Not done
Allow the author to define transformations for
imported documents that have presentation, rather than structural,
markup.[Required]
This may be part of DIS, not sure.
Remember that accessibility information,
including attributes or properties of the elements being transformed, must be
preserved - see
checkpoint 1.2.[Required] @@
This may be part of DIS, not sure.
Some examples of transformations include
(Suggested):
BR to the P element.FONT into heuristically or
author-determined structure.span into ruby.Implement XSLT [XSLT] together with a user-interface for expressing
transformations (see ATAG
2.1).(Suggested)
Don't know, Lotus have done a lot of work integrating XML and XSLT into Domino but don't really know enough about the technology to assess this check.
Can you give me a clue?CMN Not really. We should ask Lotus
Allow the author to create style rules based
on the formatting properties of an element, and then apply the rule to other
elements in the document, to assist conversion of documents to the use of
style sheets(Suggested)
Not Done
Include pre-written transformations to
rationalize multiple tables, and to transform (deprecated) presentation HTML
into style sheets.(Suggested)
Not Done
Answer
Well, there is some stuff related to accessible authoring practices and it is well integrated. There could be a lot more as this document makes clear!
If there is more than one option for the
author, and one option is more accessible than another, place the more
accessible option first and make it the default. For example, when the author
has selected text to format, the use of CSS should be emphasized rather than
deprecated FONT element.[Required] @@
Not Done, quite the reverse really
Highlight the most accessible solutions when
presenting choices for the author.(Suggested)
Domino doesn't really present choices to the author
Provide an editing view that shows
equivalent alternatives in the main content view to make it clear that they
are necessary, and will make it obvious when they are missing.(Suggested)
Not Done
This page is it: http://doc.notes.net/domino_notes/5.0.3/XML/help5_designer_XML.nsf/0/744e684a9b7f33148525687e00580d4d
There is some additional material on color="#0000ff">www.notes.net and at the IBM accessibility centre at www-3.ibm.com/able
Answer
Not done
Answer
Not done
General
All of the author's responses below are given under the caveat, that no testing has been done with accessible technology or by people with disabilities, both of which are fundamental to determining accessibility.
The document http://doc.notes.net/domino_notes/5.0.3/help5_client.nsf/0/03aacc49a076a8208525687e00740e40 how IBM has made the Notes Client accessible.
As far as I am aware all of the accessibility enhancements that were made to the Notes Client also work in the Domino Designer as they appear to spring from the same basic design.
I would like to take this opportunity to acklnowledge the work that IBM has done in this area.
ATAG 7.1 Use all applicable operating system and accessibility standards and conventions (Priority 1 for standards and conventions that are essential to accessibility; Priority 2 for those that are important to accessibility; Priority 3 for those that are beneficial to accessibility). (
See above referenced document.
ATAG 7.2 Allow the author to change the presentation within
editing views without affecting the document markup. [Priority 1] ( Checkpoint 7.2)
Answer
OK
For tools with editing views, the author must have the ability to change
the fonts, colours, sizing, etc. within the editing view, independently of
the ability to control the markup that is actually produced.
For tools that display the source structure of a document using graphic
representations of tags, provide the author with the option of displaying
the text of the elements, instead (i.e., <html> rather than 
).
An authoring tool that offers a "rendered view" of a document, such as a
browser preview mode, may provide an editing view whose presentation can be
controlled independently of the rendered view.
A WYSIWYG editor may allow an author to specify a local style sheet, that
will override the "published" style of the document in the editing view.
Allow the author to create audio style sheets using a graphical
representation rather than an audio one (with accessible representation, of
course).
Allow the author to individually edit each attribute of the elements in an
HTML or XML document, for example, through a menu. This must include the
ability to add and edit later, values for all valid attributes.
(Suggested)
OK
For tools that graphically represented element start and end tags, text
equivalent must be provided in order to be accessible to assistive
technologies that render text as Braille, speech, or large
print.(Suggested)
n/a
An authoring tool may offer several editing views of the same document,
such as a source mode that allows direct editing of all
properties.(Suggested)Not Done
For a site management tool, allow the author to render a site map in text
form (i.e., as a structured tree file).(Suggested)Can be done (need to create the view manually - there isn't an automatic one)
Allow the author to specify that alternative information (or identifiers
such as a URI or filename) are rendered in place of images or other
multimedia content while editing.(Suggested)Not Done
Include attributes / properties of elements in a view of the
structure.(Suggested)Not Done
Provide access to a list of properties via a "context menu" for each
element.(Suggested)
To minimally satisfy this checkpoint, allow navigation from element to
element.(Suggested)Answer
Not Done, arguably n/a
An authoring tool may offer a structured tree view of the document that
allows the author to move among, select and cut, copy or paste elements of
the document.(Suggested)Not Done, arguably n/a
A WYSIWYG tool may allow elements to be selected, and copied or moved while
retaining their structure.(Suggested)OK
A tool may allow transformation from one element type to another
(Suggested):Not Done
Allow the user to search for a sequence of
characters as a minimal measure for meeting this checkpoint.[Required] @@
OK
More powerful searches can include the
ability to perform searches that are case sensitive or case-insensitive, the
ability to replace a search string, the ability to repeat a previous search
to find the next or previous occurrence, or to select multiple occurrences
with a single search.(Suggested)
OK
The ability to search for a particular
type of structure is useful in a structured document, structured image such
as a complex SVG image, etc.(Suggested)
n/a
The ability to search a database for
particular content, or to search a collection of files at once (a simple
implementation of the latter is the Unix function "grep") is an important
tool in managing large collections, especially those that are dynamically
converted into Web content.(Suggested)
OK