Thread Subject: Re: Proposal (updated) 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: William Loughborough
Date: Wed, Jun 13 2007 9:40 AM

In #7 change "prominence" to "preference"?

Love.

------- Original Message -------
>From : Judy Brewer[mailto: = EMAIL ADDRESS REMOVED = ]
Sent : 6/12/2007 9:53:07 PM
To : = EMAIL ADDRESS REMOVED =
Cc :
Subject : RE: [teitac-websoftware] Proposal
(updated) on authoring tools

Dear All,

Please review the following updated proposal on
authoring tools in
preparation for our meeting tomorrow.

I have included the text brought forward from the
small group discussion
onto the Web/Software mailing list last week as the
"WAS" text below. The
"UPDATED" text represents my efforts to capture the
sense of the discussion
on the Web/Software mailing list over the past week.
The "BECAUSE"
information summarizes some of the input contributing
to the proposed
updated text. If I have missed key input or
paraphrased your input
inaccurately; please clarify. I have noted "DISCUSS"
where there are
specific issues needing discussion.

Please continue to add your comments to the mailing
list, and also be
prepared to discuss this during our meeting tomorrow.
Thank you for the
active discussion on this thread over the past week.

#1. [WAS] Authoring tools must have the ability to
produce content which
passes the electronic content provisions.
[UPDATED] Authoring tools must have the ability
to produce content
which passes the electronic content provisions for
each content format that
individual tools are capable of producing.
[BECAUSE] Otherwise one wouldn't necessarily get
accessible content
options for the full range of formats that a tool was
able to produce
(noted by Jim Tobias).
[DISCUSS] Is the additional wording sufficiently
clear, and does the
additional specificity help or hurt the intent of
this provision?

#2. [WAS] Authoring tools must, except by explicit
user action, preserve
accessibility information necessary for meeting the
electronic content
provisions.
[UPDATED] Authoring tools must preserve accessibility
information necessary
for meeting the electronic content provisions unless
the user explicitly
indicates otherwise.
[BECAUSE] Improved readability (suggestion by Sailesh)
[DISCUSS] Do we need to specify that this is for
accessibility information
"imported into, assembled by, or produced by a tool"
or is it sufficient,
or perhaps even better, to leave the source of the
accessibility
information unspecified? (from exchange between Jim T
and Judy)

#3. [WAS] Authoring tools must allow the author to
augment
automatically-generated content with accessibility
information.
[UPDATED] Authoring tools must provide a mode in
which any content that is
specified exclusively by the authoring tool must be
accessible.
[BECAUSE] This provision was drawn by the small group
out of an ATAG
provision which stated: "Ensure
automatically generated content is accessible,"
because, if accessibility
is not taken into account at the time of content
generation, it is
difficult for humans to go back later and retrofit
that content. So the
original proposal (the "WAS" version above) does not
address the same
concern which ATAG was addressing. The rewording
proposed here (the
"UPDATED" version above) attempts to address the
original problem more
clearly and directly (from explanation by Jan Richards).
[DISCUSS] Does the proposed updated text capture the
more essential need?

#4. [WAS] For authoring tools with a user interface,
authoring tools must
provide a mode which prompts authors to create
accessible content.
[UPDATED] For authoring tools with a user interface,
authoring tools must
provide a default mode which prompts authors to
create accessible content.
[BECAUSE] (1) There were some requests to drop
"authoring tools with a user
interface," however, not all authoring tools have a
user interface -- for
instance, unattended, automated tools that operate on
content. If prompting
is required as a feature within all authoring tools,
this would result in a
requirement that could not always be met (from
discussion between Peter,
Sailesh, Sean, others).
(2) A few people noted that "prompts" may be
inadequate. Recommendations
included "forced," though others noted problems with
that; or required
production of accessible content with prompting only
being used to address
ambiguities, but it is unclear how this would be
determined (from
discussion between William, David, Peter.) This
updated proposal instead
adds "default" before "mode" (from discussion between
Jim T and Judy).
(3) It was also noted that "prompting" may be
insufficiently clear (from
comments by Kate W.)
[DISCUSS] Does "provide a default mode" work here? Is
the term "prompting"
sufficiently clear?

#5. [WAS] For authoring tools with a user interface,
authoring tools must
provide a mode which assists authors in checking for
accessibility problems.
[UPDATED] (none yet)
[BECAUSE] There was debate about whether authoring
tools should be required
to provide a mode which assists authors in checking
for accessibility
problems, or whether it should be sufficient for
authoring tools to
interoperate with evaluation tools. If "authoring
tool" is defined as
"software or a collection of software components" (as
in ATAG 2.0), then
perhaps any products used together (e.g., base tool
and plug-in) or
separately (e.g., markup editor, image editor,
validation tool) would count
regardless of whether there's formal collaboration
between product
developers... in which case, does this provision make
any sense? It was
also suggested that this requirement be a "should"
instead of a "must," or
that it be dropped. But it was also noted that
authoring tools already have
spelling, syntax and grammar checking built in, and
that we can get
standalone tools for them as well.
[DISCUSS] Should authoring tools be required to
provide a checking mode,
and if so, how do we best interpret and capture that
requirement?

#6. [WAS] 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.
[UPDATED] (none yet)
[BECAUSE] It was suggested that this be a "must"
rather than a "should"
(William). It was suggested that the ability for
authors to also create
accessible templates should be included in this
provision (from Kate W.),
however isn't this already possible in most tools
that have collections of
templates? A clarification was requested for
"pre-authored content" -- the
description of this in ATAG is "Pre-authored content,
such as templates,
images, and videos,..." It was also suggested to
specify that authoring
tools should provide pre-coded accessible objects
such as buttons, tables,
templates, CSS files, form components (from Katie). A
clarification was
asked regarding "how many of the templates, how much
facilitation?"
[DISCUSS] (1) Should this be required instead of
advised? (2) Is
"pre-authored content" sufficiently clear? (3) Can
this provision be made
testable?

#7. [WAS] Authoring tools should give prominence to
the most accessible
authoring action for achieving an authoring outcome.
[UPDATED] (none)
[BECAUSE] A clarification was requested for
"prominence," and was provided
from ATAG 2.0. It was suggested that this be changed
from "should" to
"must"; but conversely it was suggested by several
people that this be
dropped.
[DISCUSS] Keep or drop?

#8. [DEFINITION] Several people asked and others
discussed the definition
of authoring tools. The following definition was
drawn from ATAG 2.0:
"...any software, or collection of software
components, that authors use to
create or modify Web content for publication." It was
also suggested that
this definition be broadened beyond Web-related
authoring tools.
[DISCUSS] Does this definition work for authoring
tools within TEITAC? Does
the definition still work if "Web" is dropped?

Regards,

- Judy


--
Judy Brewer +1.617.258.9741 http://www.w3.org/WAI
Director, Web Accessibility Initiative (WAI), World
Wide Web Consortium (W3C)
MIT/CSAIL Building 32-G526
32 Vassar Street
Cambridge, MA, 02139, USA

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