Thread Subject: Re: Proposal on authoring tools

Note

This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.

From: Walser, Kate
Date: Fri, Jun 08 2007 12:00 PM

Couple concerns & suggestions with the proposed authoring tool
guidelines numbers 4 thru 7. Proposed guideline marked with *, my
comments marked with KW.

*4. For authoring tools with a user interface, authoring tools must
provide a mode which prompts authors to create accessible content."
KW: What would this prompting entail? Are we thinking the old dialog box
pop-ups that force the developer or content author to do something
before they can continue? If so, yikes! What if I just want to mock
something up quickly OR, I'm the stuckee who needs to build out the
basic framework and have someone else fill in the things like alt tags
etc.
For some content types, prompting for the info might be a clear-cut
thing to achieve. But for others, like HTML which I work around most
often, some of the existing standards and many of the new ones we're
considering have exceptions that require human intervention. Even for
the seemingly simple image standard, exceptions occur, such as spacer
images or images with no relevant content for which I should leave the
alt tag empty so the AT can bypass it. A tool that recognizes the HTML
image tag and prompts the developer for an alt attribute would then need
to have an option that enabled the developer to leave the alt attribute
blank and an option to provide useful alternative text. The developer
might just use a space (" ") or any old text, as Peter perfectly
described, "just to get the *&% tool off of their back."
I'd suggest rephrasing this to be:
4. For authoring tools with a user interface, authoring tools must
include an option when the element is created to provide additional
accessibility information about the element. (not elegant, but hopefully
conveys the point for now and for discussion purposes)
The goal of this is to have options within the program as a tool like
Dreamweaver has that enables me to see the relevant attributes of an
item so I can populate them.

*5. For authoring tools with a user interface, authoring tools must
provide a mode which assists authors in checking for accessibility
problems.
KW: I wonder if this would make it past any federal legality checks or
past public comment given the number of vendors who provide
accessibility testing tools. Some exist already for HTML and others are
popping up. So would implementing this proposed #5 guideline prohibit
the development of new tools as there may only be so many ways to check
HTML accessibility.
Agree with Peter on this one that the "well meaning content creator will
likely use a 3rd party tool anyway" and if they don't, a new and
improved content creation tool that must pay licensing costs to include
another vendor's patented accessibility-checking capabilities to satisfy
this requirement would become cost-prohibitive for an agency who might
already have said accessibility tool as a stand-alone application.
Changing "must" to "should" makes sense, but causes #5 to lose steam and
then creates issues in testability / agency selection of products (as
said tool that integrates the features may be more expensive but better
satisfy the standards if, all else being equal, one tool satisfies this
proposed #5 and one does not (despite agency presence of accessibility
testing tools). Recommend we scratch #5.

*6. Authoring tools, when providing templates or other pre-authored
content, should provide templates that facilitate production of
accessible content, and pre-authored content that is accessible.
KW: Would #6 be more useful if it included the ability for content
authors to create these templates? Tool-provided templates are helpful,
but the ability for content author/agencies to create those templates
per their needs would be more valuable.
Also, can someone provide an example of "pre-authored content"?

*7. Authoring tools should give prominence to the most accessible
authoring action for achieving an authoring outcome.
KW: I think I get where #7 is headed - for example, in HTML, an alt
attribute rather than a title attribute is best way to provide
alternative text for an image. It's not always that clear-cut though and
this becomes untestable as it requires definitions and exceptions
abound. We'd need to define the "most accessible authoring action" for
various types of contents for this to have steam. Even if we rephrased
this to be "Authoring tools should give prominence to the most
accessible authoring action per industry standards or best practices for
achieving an accessible outcome" we'd need to define the most accessible
authoring actions which could change and require additions as
technologies evolve. Recommend scratching #7.

Cheers,
Kate

Kate Walser
Director, Usability Center of Excellence
SRA International, Inc.
4300 Fair Lakes Court
Fairfax, VA 22033
(703) 502-1170

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University