WebAIM - Web Accessibility In Mind

E-mail List Archives

Macromedia Contribute and Accessibility

for

From: Terence de Giere
Date: Feb 23, 2004 4:23PM

Having just had the opportunity to observe Macromedia Contribute in
action and its effect on web site accessibility I thought I would report
my findings as the WebAim forum group had been discussing the issue on
and off in December and January.

Beside just the issue of technical accessibility, I think the issue of
user knowledge and behavior needs to be considered as well. Contribute
is a product with a fairly simple interface and editing tools. If you
are familiar with the Windows supplied WordPad word processor and
Microsoft Word and its full capabilities, then Contribute is to
Dreamweaver as WordPad is to the full Word application. It appears to be
designed so people familiar with a simple word processor interface can
easily edit web pages.

Some friends for whom I am developing a web site as a donation really
wanted to use Macromedia Contribute to edit the site. The site was not
created in Dreamweaver, so there are no Dreamweaver templates and
comments in the files to restrict access to the various parts of pages.
The original site design was to be W3C Level Triple-A compliant. However
the graphical design desired by my friends and the time I have to work
on this reduced that potential accessibility to about Level A or Section
508. Nonetheless a lot of accessibility remained, and although tables
were used for overall format and the navigation structure, the content
area of the pages are fairly clean in that headings, paragraphs and
lists were all used according to specification.

A linked Cascading Style Sheet provided all the finer format details.
The linked sheet used the @import rule to import the main style sheet
for the site to exclude some of the older browsers that have poor
support for CSS2. I also tested the same page with a single linked style
sheet without the @import rule. In neither case did Contribute display
the format provided by the linked style sheets in EDIT mode. A page will
look pretty much as it would in a pre-CSS browser. This might cause some
consternation with users who suddenly see format disappear when moving
into EDIT mode. They may try to then apply their own format. If the
style sheet was embedded in the STYLE element in the page header, then
only did the CSS format show in Contribute's edit mode, but not quite as
well as in current browsers. Also with the embedded style sheet but not
linked style sheets, styles based on the class attribute (.classname)
showed in the styles menu. Unlike Dreamweaver which can display linked
styles of some sophistication in its graphical mode, Contribute is
useless here. If style sheets are desired, then the bulk of adding them
to every page is required which undermines the simplicity and
compactness and scope of global style sheets.

There is some attention to accessibility, but not in a way a user can
really control. There are some simple preset data table layouts that use
the 'scope' attribute to associate headers with the data, but that is
all. EM and STRONG are by default used for bold and italic text. For
fonts, the FONT element is used by default, although the Contribute
administrator can reset this to use CSS. All CSS changes in the page
used local in line CSS, which will override a linked or embedded style
sheet. Users would need to be informed not to change font sizes, faces
etc. in a site that used a complex linked CSS format. As already
mentioned on the forum, BLOCKQUOTE is incorrectly used to indent text.
Ordered and unordered lists can be created from the toolbar but not
definition lists. Document Types like HTML 4.01 strict or XHTML 1.0
strict, or XHTML1.1 may become invalid when Contribute inserts elements
not found in those DTDs, as Macromedia products cannot enforce a
particular Document Type Definition.

I set up Contribute and got to observe what happened to the format and
accessibility and general HTML structure as a person with typical
knowledge of a word processor edited the site. Editing is entirely
visual. The check-in and check-out system seemed to work well, with a
checked out file not available to edit until it is checked back in by
whoever is working on it. This appears to be controlled by files on the
site which Contribute and Dreamweaver access before processing any
files. There may be some hidden files these applications place on the
site, as well as a visible XML files in a directory created on the site.
With regular FTP access these restriction do not apply, they are meant
to be kept inside the Macromedia world of applications, so someone could
bypass these restrictions if they had site access and used FTP or an FTP
application to get at the files.

In this situation, just about everything got messed up.

A template for a definition list was taken by the user who reformatted
it. The result was a list that included both the term and the definition
on a single line in the DT element, the dfinition term. The DD element,
reserved for the definition or explanation of the term was cut out. The
style sheet had formatted the DT element as bold, but it was overridden
with a local CSS bold after the user edited it. Under the format menu
items in Contribute, not the tool bars, a definition list is an option.

When I tried to create a definition list on a page using the menu item,
visually it was not clear what I was seeing. I ended up with the content
in a paragraph below the list code. On a blank page I got the definition
term in the right place but there was no visual clue as to how to
contruct the rest of the list. I finally discovered hitting the ENTER
key created the DD element so I could enter the definition. Maybe I am
just stupid, but I normally use SGML or XML applications, or hand coding
to make these lists. This shows that user behavior, even with some
competent knowledge can bring about suprising results when using a new tool.

On another page the user created his own bulleted list. He did not use
the list controls in Contribute, but built the list in a paragraph using
the BR (line break) element, and a Unicode bullet character, creating
just the appearance of a list. I had to rebuild this into a real
unordered list.

A picture caption, which was a paragraph designed to be one short line
that had special CSS format to partly overlap the picture became a total
mess as the user added a long string of explanation causing the lines to
wrap. This site is not being formally built, but these user behaviors
indicate that a clear well thought out style guide that is written out
as an organizational standard should be on hand for anyone editing a
site because otherwise who knows what will happen.

The user created some very long link text trying to explain as much as
possible to the site visitor, resulting in links that wrapped to three
lines. These were hard to read visually.

My feeling with this very short exposure to Contribute, is the program
is inadequate for an accessibility knowledgeable user to edit a site -
Dreamweaver or any other editor that allows the user to control the HTML
precisely should be preferred over Contribute. And for the less
knowledgeable, it seems that the innate tendency to build web pages
using visual only constructions will undermine the accessibility on a
site. I have seen this over and over - accessibility declines as more
users of various levels of experience edit a site. Contribute basically
is a visual interface, and many crucial accessibility details are
hidden. For example a paragraph is called 'normal' text. A paragraph
with an ID attribute is not named at all. Contribute does list headings.
But all and all, it seems Contribute's simplicity and its hiding of the
details of what accessibility it does support make it a difficult choice
as an editor for a site.

The code after editing in contribute seemed to have a lot more white
space, adding some bulk and download time to files.

I have not in this short time found all of the program's strengths, but
it has enough weaknesses in its use, and with user behavior that I would
not want it to be used on an accessible site. Contribute would seem to
work best with sites that use the kind of coding that in the past
strongly contributed to inaccessibility of sites. The more accessible a
site is, the more time might have to be spent re-establishing good
accessible code after editing with Contribute. Macromedia has a tutorial
for administrators (which I have not read) which may contain more
details for controlling the user. There is also an XML file
'contribute.xml' that contains a number of instructions that offer some
hope here, this controls user settings for Contribute. I think the
content below represents the default values for Contribute. These values
are changed by administrators when setting up Contribute.

<group_name value='Users' />
<group_enabled value='true' />
<group_home_page value='http://www.domainname.com/index.htm' />
<group_description value='Members of this permission group
are users of this website.' />
<group_copy_page_list>
</group_copy_page_list>
<group_show_all_templates value='true' />
<group_allow_delete_files value='false' />
<group_allow_delete_rollbacks value='false' />
<group_templates_list>
</group_templates_list>
<group_full_edit_access value='true' />
<group_edit_access_list>
</group_edit_access_list>
<style_user_can_change value='true' />
<style_use_standard_html value='true' />
<style_use_css value='true' />
<font_user_can_change value='true' />
<font_use_font_tag value='true' />
<font_use_css value='true' />
<font_units value='' />
<font_list></font_list>
<edit_text_only_in_non_templates value='false' />
<edit_allow_code_deletion value='false' />
<edit_allow_multiple_spaces value='true' />
<edit_single_line_paragraphs_use_css value='true' />
<edit_use_strong_and_em value='true' />
<edit_show_accessibility_options value='false' />
<edit_line_ending value='3338' />
<new_allow_blank_docs value='true' />
<new_allow_example_docs value='true' />
<new_allow_copy_docs value='true' />
<new_unlimited_image_size value='true' />
<new_max_image_size_k value='64' />

The following is from the Contribute Help System - there is an enforce
accessibility control in Contribute but it seems limited to ALT text and
if you create a table from pre made templates, table header cells:

"Also, as you edit your pages, remember that
some visitors will be using screen readers.
Contribute helps you make your images
and tables more accessible in the following ways:

* You can add text that screen readers will
recite to describe images in your pages.
* Your website administrator can have
Contribute prompt you for descriptive
text whenever you insert an image.
* For more information, talk to you website
administrator or see Setting page editing
and paragraph permissions <33_per11.htm#wp74500>.
* You can include table headings to be recited
by screen readers. To insert tables with
headings, see Inserting a table on a page <08_tabl3.htm#wp75617>.

*Note: *Screen readers do not read boldface headings centered
in a row or column."

Contribute Help indicates it is compatible with JAWS and Window Eyes
screen readers.

Most of the accessibility information in Contribute refers the user to
the usual places - the W3C WAI and Section 508.

I hope