ATAG 7.2 to 7.7 and Top Page tool

IBM developers assessed TopPage and WebSphere Studio against the checklist and
made the following observations regarding checkpoints 7.2 through 7.7.  This can
serve as a discussion point in our face-to-face and/or as background for the
techniques document:

IBM TopPage and WebSphere Studio have at least 4 editing "views" that can be
selected and switched to back and forth while authoring a document or site.
There is a traditional WYSIWYG view, an HTML source view, a document structure
view [known as the universal attribute editor], and pop-up dialogs such as a URL
editor that included links, images, etc. The actual accessibility of these 4
"editing views" is reserved for another discussion.  There are also "render
views", as I'll call them,  that show the page as it would look in IE or
Netscape with the ability to add browsers [Lynx for text view, Home Page Reader
for voice, etc.], but of course you can't *edit* in these views.  There is also
an "after the editing" tool to check a whole site for spelling and alt text or
create a site map.  HTML validation is done while editing and/or saving and
loading.  Keep these features in mind as you review the answers to checkpoints
7.2 through 7.7:

7.2 Allow the author to change the editing view without affecting the document
markup. Priority 1
This allows the author to edit the document according to their personal
requirements, without changing the way the document looks or is rendered when
published.
Yes, because all  editing views can be selected and switched between without
affecting the document markup. These views should be compatible with screen
readers and magnifiers but not yet verified.  The page can also be previewed in
any browser.

7.3 Render an accessible equivalent of each element property. [Priority 1]
Yes, because the HTML source and document structure views are equivalent views
of the WYSIWYG view of the elements that make up the page.  This checkpoint
seems redundant with 7.4.  If it can't be rendered, how can it be edited.  If
the spec is talking about "previews" by different browsers, then it's not a P1
nor a needed checkpoint for the tool developer since the author has complete
control over which browsers he want's to "preview" pages in.

7.4 Allow the author to edit all properties of each element and object in an
accessible fashion. [Priority 1]
Yes, continuing from 7.3, because each element and it's attributes and value are
editable in multiple ways.  There is even the capability to "add" attributes and
to of course edit the values of those attributes.

7.5 Ensure the editing view allows navigation via the structure of the document.
[Priority 1]
Yes. because the page structure tree view is provided, and you can easily
navigate from element to element, expanding and collapsing each element. There
is also a heading view and a link view.

7.6 Enable editing of the structure of the document. [Priority 2]
Yes, because while navigating the structured tree view,  you can edit the
attributes of the elements.  There is also complete copy/paste of structure
elements.  The contents of the elements are not editable from the tree view, for
example the H1 attributes are editable, but the actual H1 text is available to
be edited in the source, WYSIWYG, and headings view.

7.7 Allow the author to search within editing views. [Priority 2]
Yes, there are extensive search and replace capabilites.

Any comments?

Regards,
Phill Jenkins

Received on Tuesday, 5 October 1999 18:37:07 UTC