Thread Subject: Proposal on authoring tools

Return to this mailing list's archives

From: Judy Brewer
Date: Wed, Jun 06 2007 11:35 PM
Subject: Proposal on authoring tools

The following proposal on authoring tools represents current work in
progress by a small group following the recent TEITAC face-to-face meeting.
Please add your comments as we continue to work on this, now on the
Web/Software list. For those who already contributed in the small group,
thank you for your input on the draft; the latest version here attempts to
capture your most recent feedback in our discussion, but please continue to
help refine this on the Web software list now.

1. Authoring tools must have the ability to produce content which passes
the electronic content provisions.

2. Authoring tools must, except by explicit user action, preserve
accessibility information necessary for meeting the electronic content
provisions.

3. Authoring tools must allow the author to augment automatically-generated
content with accessibility information.

4. For authoring tools with a user interface, authoring tools must provide
a mode which prompts authors to create accessible content.

5. For authoring tools with a user interface, authoring tools must provide
a mode which assists authors in checking for accessibility problems.

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.

7. Authoring tools should give prominence to the most accessible authoring
action for achieving an authoring outcome.

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

From: Jim Tobias
Date: Thu, Jun 07 2007 4:40 AM
Subject: Re: Proposal on authoring tools

Thanks for this, Judy. I've added comments inside brackets [ ] for some
provisions; I agree with the others.

This reminds me of the other, semi-non-procurement issues regarding content:

1. Provision 5.A says "each agency shall ... activate accessibility features
and configure telecommunications products so that they are accessible to and
usable by people with disabilities." There has been discussion about
globalizing
this provision so that it applies to all products and services, and
authoring tools are clearly the biggest set of applicable products. How
should it read for that purpose?

2. We need a provision requiring content authoring tools to include
documentation on how to create accessible content. Should this be in the
Documentation section?

3. We need a provision requiring agencies to develop and disseminate a
policy on the creation of accessible content. I know that this may not be
enforceable.

***
Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias


> -----Original Message-----
> From: Judy Brewer [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Thursday, June 07, 2007 1:32 AM
> To: = EMAIL ADDRESS REMOVED =
> Subject: [teitac-websoftware] Proposal on authoring tools
>
> The following proposal on authoring tools represents current
> work in progress by a small group following the recent TEITAC
> face-to-face meeting.
> Please add your comments as we continue to work on this, now
> on the Web/Software list. For those who already contributed
> in the small group, thank you for your input on the draft;
> the latest version here attempts to capture your most recent
> feedback in our discussion, but please continue to help
> refine this on the Web software list now.
>
> 1. Authoring tools must have the ability to produce content
> which passes the electronic content provisions [ADD:for each content
format it is capable of producing].
>
> 2. Authoring tools must, except by explicit user action,
> preserve accessibility information necessary for meeting the
> electronic content provisions. [Is this for content imported into
the tool from another source? If so, that should be explicit.]
>
> 3. Authoring tools must allow the author to augment
> automatically-generated content with accessibility information.
>
> 4. For authoring tools with a user interface, authoring tools
> must provide a mode which prompts authors to create
> accessible content. [This should be the default mode.]
>
> 5. For authoring tools with a user interface, authoring tools
> must provide a mode which assists authors in checking for
> accessibility problems.
>
> 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.
>
> 7. Authoring tools should give prominence to the most
> accessible authoring action for achieving an authoring outcome.
[I'm not sure about this --- do you mean prominence in general, or
prominence in a list of options, or what?]

From: Jim Tobias
Date: Thu, Jun 07 2007 4:45 AM
Subject: Re: Proposal on authoring tools

Thanks for this, Judy. I've added comments inside brackets [ ] for some
provisions; I agree with the others.

This reminds me of the other, semi-non-procurement issues regarding content:

1. Provision 5.A says "each agency shall ... activate accessibility features
and configure telecommunications products so that they are accessible to and
usable by people with disabilities." There has been discussion about
globalizing
this provision so that it applies to all products and services, and
authoring tools are clearly the biggest set of applicable products. How
should it read for that purpose?

2. We need a provision requiring content authoring tools to include
documentation on how to create accessible content. Should this be in the
Documentation section?

3. We need a provision requiring agencies to develop and disseminate a
policy on the creation of accessible content. I know that this may not be
enforceable.

***
Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias


> -----Original Message-----
> From: Judy Brewer [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Thursday, June 07, 2007 1:32 AM
> To: = EMAIL ADDRESS REMOVED =
> Subject: [teitac-websoftware] Proposal on authoring tools
>
> The following proposal on authoring tools represents current
> work in progress by a small group following the recent TEITAC
> face-to-face meeting.
> Please add your comments as we continue to work on this, now
> on the Web/Software list. For those who already contributed
> in the small group, thank you for your input on the draft;
> the latest version here attempts to capture your most recent
> feedback in our discussion, but please continue to help
> refine this on the Web software list now.
>
> 1. Authoring tools must have the ability to produce content
> which passes the electronic content provisions [ADD:for each content
format it is capable of producing].
>
> 2. Authoring tools must, except by explicit user action,
> preserve accessibility information necessary for meeting the
> electronic content provisions. [Is this for content imported into
the tool from another source? If so, that should be explicit.]
>
> 3. Authoring tools must allow the author to augment
> automatically-generated content with accessibility information.
>
> 4. For authoring tools with a user interface, authoring tools
> must provide a mode which prompts authors to create
> accessible content. [This should be the default mode.]
>
> 5. For authoring tools with a user interface, authoring tools
> must provide a mode which assists authors in checking for
> accessibility problems.
>
> 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.
>
> 7. Authoring tools should give prominence to the most
> accessible authoring action for achieving an authoring outcome.
[I'm not sure about this --- do you mean prominence in general, or
prominence in a list of options, or what?]

From: David Poehlman
Date: Thu, Jun 07 2007 6:20 AM
Subject: Re: Proposal on authoring tools

Hi Judy and all,

Should the iaccessability of the interface be addressed here or give
reference to other standards?
----- Original Message -----
From: "Judy Brewer" < = EMAIL ADDRESS REMOVED = >
To: < = EMAIL ADDRESS REMOVED = >
Sent: Thursday, June 07, 2007 1:32 AM
Subject: [teitac-websoftware] Proposal on authoring tools


The following proposal on authoring tools represents current work in
progress by a small group following the recent TEITAC face-to-face meeting.
Please add your comments as we continue to work on this, now on the
Web/Software list. For those who already contributed in the small group,
thank you for your input on the draft; the latest version here attempts to
capture your most recent feedback in our discussion, but please continue to
help refine this on the Web software list now.

1. Authoring tools must have the ability to produce content which passes
the electronic content provisions.

2. Authoring tools must, except by explicit user action, preserve
accessibility information necessary for meeting the electronic content
provisions.

3. Authoring tools must allow the author to augment automatically-generated
content with accessibility information.

4. For authoring tools with a user interface, authoring tools must provide
a mode which prompts authors to create accessible content.

5. For authoring tools with a user interface, authoring tools must provide
a mode which assists authors in checking for accessibility problems.

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.

7. Authoring tools should give prominence to the most accessible authoring
action for achieving an authoring outcome.

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

From: Hoffman, Allen
Date: Thu, Jun 07 2007 7:10 AM
Subject: Re: Proposal on authoring tools

The sub-group of us who looked at this agreed mostly that the software
and web standards already proposed will cover the accessibility of the
interface. One item in ATAG has is a note that prevews of content be
accessible via the mark up, (will find the specific language). i think
this is still indirectly addressed by our existing proposed web/software
provisions.





Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of David
Poehlman
Sent: Thursday, June 07, 2007 8:15 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Proposal on authoring tools

Hi Judy and all,

Should the iaccessability of the interface be addressed here or give
reference to other standards?
----- Original Message -----
From: "Judy Brewer" < = EMAIL ADDRESS REMOVED = >
To: < = EMAIL ADDRESS REMOVED = >
Sent: Thursday, June 07, 2007 1:32 AM
Subject: [teitac-websoftware] Proposal on authoring tools


The following proposal on authoring tools represents current work in
progress by a small group following the recent TEITAC face-to-face
meeting.
Please add your comments as we continue to work on this, now on the
Web/Software list. For those who already contributed in the small group,
thank you for your input on the draft; the latest version here attempts
to capture your most recent feedback in our discussion, but please
continue to help refine this on the Web software list now.

1. Authoring tools must have the ability to produce content which passes
the electronic content provisions.

2. Authoring tools must, except by explicit user action, preserve
accessibility information necessary for meeting the electronic content
provisions.

3. Authoring tools must allow the author to augment
automatically-generated content with accessibility information.

4. For authoring tools with a user interface, authoring tools must
provide a mode which prompts authors to create accessible content.

5. For authoring tools with a user interface, authoring tools must
provide a mode which assists authors in checking for accessibility
problems.

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.

7. Authoring tools should give prominence to the most accessible
authoring action for achieving an authoring outcome.

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

From: Judy Brewer
Date: Thu, Jun 07 2007 8:00 AM
Subject: Re: Proposal on authoring tools

Hi David,

We had some small group discussion of this, and people remarked that
authoring tool user interface accessibility seemed to be generally covered
by TEITAC software provisions on user interface accessibility. We therefore
focused our energy on bringing forward a proposal on support for production
of accessible content.

However, it was also noted that it was possible that a few ATAG 2.0
provisions regarding accessibility of the user interface specific to
authoring tools might not be sufficiently covered by the TEITAC user
interface provisions. In my opinion it might still be useful to look
through those provisions (A.1.1 through A.4.4) in the latest ATAG 2.0
Working Draft
http://www.w3.org/WAI/AU/2007/WD-ATAG20-20070530/WD-ATAG20-20070530#part-tool-accessible
and make sure that the essentials needed for people with disabilities to be
able to author content are covered. For instance, you might want to look at
A.3.8, [For the authoring tool user interface] "Ensure [that] previews are
as accessible as existing user agents" which is one of the few that doesn't
seem to be already covered under the general software provisions. But if
relevant, it might be more appropriate to propose that under the software
provisions than under this section on authoring tools.

- Judy

At 08:14 AM 6/7/2007 -0400, David Poehlman wrote:
>Hi Judy and all,
>
>Should the iaccessability of the interface be addressed here or give
>reference to other standards?
>----- Original Message -----
>From: "Judy Brewer" < = EMAIL ADDRESS REMOVED = >
>To: < = EMAIL ADDRESS REMOVED = >
>Sent: Thursday, June 07, 2007 1:32 AM
>Subject: [teitac-websoftware] Proposal on authoring tools
>
>
>The following proposal on authoring tools represents current work in
>progress by a small group following the recent TEITAC face-to-face meeting.
>Please add your comments as we continue to work on this, now on the
>Web/Software list. For those who already contributed in the small group,
>thank you for your input on the draft; the latest version here attempts to
>capture your most recent feedback in our discussion, but please continue to
>help refine this on the Web software list now.
>
>1. Authoring tools must have the ability to produce content which passes
>the electronic content provisions.
>
>2. Authoring tools must, except by explicit user action, preserve
>accessibility information necessary for meeting the electronic content
>provisions.
>
>3. Authoring tools must allow the author to augment automatically-generated
>content with accessibility information.
>
>4. For authoring tools with a user interface, authoring tools must provide
>a mode which prompts authors to create accessible content.
>
>5. For authoring tools with a user interface, authoring tools must provide
>a mode which assists authors in checking for accessibility problems.
>
>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.
>
>7. Authoring tools should give prominence to the most accessible authoring
>action for achieving an authoring outcome.
>
>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
>
>

From: Brad Hodges
Date: Thu, Jun 07 2007 8:10 AM
Subject: Re: Proposal on authoring tools

Greetings:

I suggest the following as an additional requirement.

For authoring tools with a user interface, authoring tools must provide
a mode, or administrative option to require the use of accessibility
features.

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Judy
Brewer
Sent: Thursday, June 07, 2007 1:32 AM
To: = EMAIL ADDRESS REMOVED =
Subject: [teitac-websoftware] Proposal on authoring tools

The following proposal on authoring tools represents current work in
progress by a small group following the recent TEITAC face-to-face
meeting.
Please add your comments as we continue to work on this, now on the
Web/Software list. For those who already contributed in the small group,
thank you for your input on the draft; the latest version here attempts
to capture your most recent feedback in our discussion, but please
continue to help refine this on the Web software list now.

1. Authoring tools must have the ability to produce content which passes
the electronic content provisions.

2. Authoring tools must, except by explicit user action, preserve
accessibility information necessary for meeting the electronic content
provisions.

3. Authoring tools must allow the author to augment
automatically-generated content with accessibility information.

4. For authoring tools with a user interface, authoring tools must
provide a mode which prompts authors to create accessible content.

5. For authoring tools with a user interface, authoring tools must
provide a mode which assists authors in checking for accessibility
problems.

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.

7. Authoring tools should give prominence to the most accessible
authoring action for achieving an authoring outcome.

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

From: Gregg Vanderheiden
Date: Thu, Jun 07 2007 8:40 AM
Subject: Re: Proposal on authoring tools

Agree that we shouldn't repeat the general software access provisions here.

We should probably include a note (and this might be a more general issue
for EWG) that makes it clear that these are ADDITIONAL provision. Maybe
just using the title "additional provisions for authoring software".
Using "software" instead of "tools" may also help reinforce the fact that
the software rules would apply.

Also, if there are some important provisions missing for access to authoring
software then we probably should consider those for the software access
section in general.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Judy Brewer
> Sent: Thursday, June 07, 2007 8:46 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Proposal on authoring tools
>
> Hi David,
>
> We had some small group discussion of this, and people
> remarked that authoring tool user interface accessibility
> seemed to be generally covered by TEITAC software provisions
> on user interface accessibility. We therefore focused our
> energy on bringing forward a proposal on support for
> production of accessible content.
>
> However, it was also noted that it was possible that a few
> ATAG 2.0 provisions regarding accessibility of the user
> interface specific to authoring tools might not be
> sufficiently covered by the TEITAC user interface provisions.
> In my opinion it might still be useful to look through those
> provisions (A.1.1 through A.4.4) in the latest ATAG 2.0
> Working Draft
> http://www.w3.org/WAI/AU/2007/WD-ATAG20-20070530/WD-ATAG20-200
> 70530#part-tool-accessible
> and make sure that the essentials needed for people with
> disabilities to be able to author content are covered. For
> instance, you might want to look at A.3.8, [For the authoring
> tool user interface] "Ensure [that] previews are as
> accessible as existing user agents" which is one of the few
> that doesn't seem to be already covered under the general
> software provisions. But if relevant, it might be more
> appropriate to propose that under the software provisions
> than under this section on authoring tools.
>
> - Judy
>
> At 08:14 AM 6/7/2007 -0400, David Poehlman wrote:
> >Hi Judy and all,
> >
> >Should the iaccessability of the interface be addressed here or give
> >reference to other standards?
> >----- Original Message -----
> >From: "Judy Brewer" < = EMAIL ADDRESS REMOVED = >
> >To: < = EMAIL ADDRESS REMOVED = >
> >Sent: Thursday, June 07, 2007 1:32 AM
> >Subject: [teitac-websoftware] Proposal on authoring tools
> >
> >
> >The following proposal on authoring tools represents current work in
> >progress by a small group following the recent TEITAC
> face-to-face meeting.
> >Please add your comments as we continue to work on this, now on the
> >Web/Software list. For those who already contributed in the small
> >group, thank you for your input on the draft; the latest
> version here
> >attempts to capture your most recent feedback in our discussion, but
> >please continue to help refine this on the Web software list now.
> >
> >1. Authoring tools must have the ability to produce content which
> >passes the electronic content provisions.
> >
> >2. Authoring tools must, except by explicit user action, preserve
> >accessibility information necessary for meeting the
> electronic content
> >provisions.
> >
> >3. Authoring tools must allow the author to augment
> >automatically-generated content with accessibility information.
> >
> >4. For authoring tools with a user interface, authoring tools must
> >provide a mode which prompts authors to create accessible content.
> >
> >5. For authoring tools with a user interface, authoring tools must
> >provide a mode which assists authors in checking for
> accessibility problems.
> >
> >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.
> >
> >7. Authoring tools should give prominence to the most accessible
> >authoring action for achieving an authoring outcome.
> >
> >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
> >
> >

From: Sailesh Panchang
Date: Thu, Jun 07 2007 9:20 AM
Subject: Re: Proposal on authoring tools

>2. Authoring tools must, except by explicit user action, preserve
>accessibility information necessary for meeting the electronic content
>provisions.
On reading the statement I am not sure I understand "except by explicit
user action, ". Does it mean:
2. Authoring tools must preserve accessibility information necessary for
meeting the electronic content provisions unless the user explicitly
indicates otherwise.

>4. For authoring tools with a user interface, authoring tools must provide
>a mode which prompts authors to create accessible content.
Is "For authoring tools with a user interface, ", required? For user driven
authoring tools, a user interface is certainly needed and if it is an
automated authoring tool, it should provide a programmable switch or
parameter by which one can turn on / off this mode. So I think it
should simply read:
4. Authoring tools must provide a mode which prompts authors to create
accessible content.

5. For authoring tools with a user interface, authoring tools must provide a
mode which assists authors in checking for accessibility problems.
Evaluation techniques may be very difficult to incorporate into authoring
tools. Perhaps the guideline should state:
User-driven authoring tools must provide a mode which assists authors in
checking for accessibility problems directly or via a separate interface. I
mean like a plug-in.

About #6 that requires accessibility enabled templates: Templates may be
desirable and a tool that offers these may have an advantage over another.
But I am not sure this should be a requirement. In fact I feel the same way
about authoring tools directly providing the ability to evaluate
accessibility.
Admittedly templates and eval capability will help authors become more
accessibility conscious and encourage development of accessible content, but
is it a reasonable requirement? Some diagnostic capability could perhaps be
incorporated directly but how thorough and effective can it get? Limited and
haphazard evaluation capabilities may end up being a disservice to
accessibility. The focus of authoring tools should be on ability to produce
valid code while permitting users to incorporate all the accessibility
features offered by the technology and ensuring the authoring interface is
accessible.

>7. Authoring tools should give prominence to the most accessible authoring
>action for achieving an authoring outcome.
Not sure I understand "give prominence to the most accessible authoring
action for achieving an authoring outcome ". Can this be clearer?
Sailesh Panchang
Senior Accessibility Engineer
Deque Systems Inc. (www.deque.com)
11130 Sunrise Valley Drive, Suite #140,
Reston VA 20191
Phone: 703-225-0380 (ext 105)
E-mail: = EMAIL ADDRESS REMOVED =

From: love26@gorge.net
Date: Thu, Jun 07 2007 10:25 AM
Subject: Re: Proposal on authoring tools

------- Original Message -------
>From : Judy Brewer[mailto: = EMAIL ADDRESS REMOVED = ]

4. For authoring tools with a user interface, authoring tools must provide
a mode which prompts authors to create accessible content.

Can't we get a bit stronger than "prompts"? Although I sort of lean towards
"forces", there are other choices.

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.
7. Authoring tools should give prominence to the most accessible authoring
action for achieving an authoring outcome.

both of the "shoulds" in these two ought to be stronger, say "must"?

Love.

From: Judy Brewer
Date: Thu, Jun 07 2007 10:30 AM
Subject: Re: Proposal on authoring tools

Hi Jim,

Thanks. Replying first to your latter batch of comments first (your inline
comments in brackets [ ] below):

At 06:39 AM 6/7/2007 -0400, Jim Tobias wrote:
>Thanks for this, Judy. I've added comments inside brackets [ ] for some
>provisions; I agree with the others.
><...>
> > 1. Authoring tools must have the ability to produce content
> > which passes the electronic content provisions [ADD:for each content
>format it is capable of producing].

Good point -- otherwise one wouldn't necessarily get accessible content
options for the full range of formats that a tool was able to produce.

> > 2. Authoring tools must, except by explicit user action,
> > preserve accessibility information necessary for meeting the
> > electronic content provisions. [Is this for content imported into
>the tool from another source? If so, that should be explicit.]

I believe that the intent of our discussion was that it be for content
imported into, assembled by, or produced by a tool. So if we add a
clarification, we'd need to add the whole string, and perhaps scrub it up
better than my wording here.

> > 4. For authoring tools with a user interface, authoring tools
> > must provide a mode which prompts authors to create
> > accessible content. [This should be the default mode.]

Would this wording capture your intent:
"...authoring tools must provide a default mode which prompts..."
-- or --
"...the default mode of operation must prompt authors to..."
-- or, re-using the language from #2 above --
"...except by explicit user action, authoring tools must prompt..."
Any preference? Reactions?

> > 7. Authoring tools should give prominence to the most
> > accessible authoring action for achieving an authoring outcome.
>[I'm not sure about this --- do you mean prominence in general, or
>prominence in a list of options, or what?]

I do not suggest including all of the following detail, but this background
may be useful for our discussion. Please see the guidance in the ATAG 2.0
Working Draft for B.3.1,
<http://www.w3.org/WAI/AU/2007/WD-ATAG20-20070530/WD-ATAG20-20070530.html#check-give-priority>
particularly the rationale, success criteria, and definition which I've
pasted here for reference:

Rationale:
"Authors are most likely to use the first and easiest authoring action they
encounter in the authoring tool user interface that achieves their intended
authoring outcome"

Level A Success Criteria for Guideline B.3.1:
"B.3.1.1 At Least as Prominent: If the authoring tool provides more than
one authoring action that achieves the same authoring outcome, then any of
these actions that utilize accessible authoring practices must be at least
as prominent as any of these action(s) that do not (@@e.g., if tabular data
can be added using preformatted text or table markup, the more accessible
table markup practice is more prominent)."

Definition: Prominence
<http://www.w3.org/WAI/AU/2007/WD-ATAG20-20070530/WD-ATAG20-20070530.html#def-Prominence>
"A heuristic measure of the degree to which authors are likely to notice
controls in the authoring tool user interface when operating the authoring
tool. In this document, prominence refers to visual as well as
keyboard-driven navigation. Some of the factors that contribute to the
prominence of a control include:
1. Control size (large controls or controls surrounded by extra white
space may appear to be conferred higher importance),
2. Control order (items that occur early in the "localized" reading
order (e.g., left to right and top to bottom; right to left and top to
bottom) are conferred higher importance),
3. Control grouping (grouping controls together can change the reading
order and the related judgments of importance),
4. advanced options (when the properties are explicitly or implicitly
grouped into sets of basic and advanced properties, the basic properties
may gain apparent importance), and Highlighting (controls may be
distinguished from others using icons, color, styling)."

- 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

From: Peter Korn
Date: Thu, Jun 07 2007 11:00 AM
Subject: Re: Proposal on authoring tools

Hi William,

> 4. For authoring tools with a user interface, authoring tools must provide a mode which prompts authors to create accessible content.
>
> Can't we get a bit stronger than "prompts"? Although I sort of lean towards "forces", there are other choices.
>

There is no way a tool can know that the information a user enters is
the correct information (e.g. is the description of a graphic a useful
one that makes the graphic accessible?). There are too many cases
requiring judgment calls. Further, there are situations in which more
information isn't helpful - it is sometimes quite appropriate to NOT
enter information (e.g. obvious user interface elements only need a
"name", not also a "description", and putting a lengthy and unnecessary
description in that gets read by a screen reader can actually be a
burden to people with disabilities).

I think "forces" or something like it will actually generate problems in
many situations.

> 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.
> 7. Authoring tools should give prominence to the most accessible authoring action for achieving an authoring outcome.
>
> both of the "shoulds" in these two ought to be stronger, say "must"?
>

One big concern with #7 is that the "most accessible authoring action"
is often not testable. It is certainly somewhat subjective. I think
this has to be advisory, relying on the best judgment of folks making
the tool.

With #6, we again have a lot of judgment calls involved in templates -
how many of the templates, how much facilitation? Things that are
"musts" need to be testable; I don't know how to test this.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

From: David Poehlman
Date: Thu, Jun 07 2007 11:50 AM
Subject: Re: Proposal on authoring tools

and is not valid code accessible code as we are expressing it? is word and
acrobat not an authoring environment? do they not have spellin and grammar
checkers in them as well as other checkers? does not acrobat reader for
instance have an accesibility checker in it? it is not unreasonable to
demand these tasks.
----- Original Message -----
From: "Sailesh Panchang" < = EMAIL ADDRESS REMOVED = >
To: "'TEITAC Web/Software Subcommittee'"
< = EMAIL ADDRESS REMOVED = >
Sent: Thursday, June 07, 2007 11:18 AM
Subject: Re: [teitac-websoftware] Proposal on authoring tools


>2. Authoring tools must, except by explicit user action, preserve
>accessibility information necessary for meeting the electronic content
>provisions.
On reading the statement I am not sure I understand "except by explicit
user action, ". Does it mean:
2. Authoring tools must preserve accessibility information necessary for
meeting the electronic content provisions unless the user explicitly
indicates otherwise.

>4. For authoring tools with a user interface, authoring tools must provide
>a mode which prompts authors to create accessible content.
Is "For authoring tools with a user interface, ", required? For user driven
authoring tools, a user interface is certainly needed and if it is an
automated authoring tool, it should provide a programmable switch or
parameter by which one can turn on / off this mode. So I think it
should simply read:
4. Authoring tools must provide a mode which prompts authors to create
accessible content.

5. For authoring tools with a user interface, authoring tools must provide a
mode which assists authors in checking for accessibility problems.
Evaluation techniques may be very difficult to incorporate into authoring
tools. Perhaps the guideline should state:
User-driven authoring tools must provide a mode which assists authors in
checking for accessibility problems directly or via a separate interface. I
mean like a plug-in.

About #6 that requires accessibility enabled templates: Templates may be
desirable and a tool that offers these may have an advantage over another.
But I am not sure this should be a requirement. In fact I feel the same way
about authoring tools directly providing the ability to evaluate
accessibility.
Admittedly templates and eval capability will help authors become more
accessibility conscious and encourage development of accessible content, but
is it a reasonable requirement? Some diagnostic capability could perhaps be
incorporated directly but how thorough and effective can it get? Limited and
haphazard evaluation capabilities may end up being a disservice to
accessibility. The focus of authoring tools should be on ability to produce
valid code while permitting users to incorporate all the accessibility
features offered by the technology and ensuring the authoring interface is
accessible.

>7. Authoring tools should give prominence to the most accessible authoring
>action for achieving an authoring outcome.
Not sure I understand "give prominence to the most accessible authoring
action for achieving an authoring outcome ". Can this be clearer?
Sailesh Panchang
Senior Accessibility Engineer
Deque Systems Inc. (www.deque.com)
11130 Sunrise Valley Drive, Suite #140,
Reston VA 20191
Phone: 703-225-0380 (ext 105)
E-mail: = EMAIL ADDRESS REMOVED =

From: love26@gorge.net
Date: Thu, Jun 07 2007 11:55 AM
Subject: Re: Proposal on authoring tools

------- Original Message -------
>From : Peter Korn[mailto: = EMAIL ADDRESS REMOVED = ]

I think "forces" or something like it will actually
generate problems in
many situations.

One big concern with #7 is that the "most accessible
authoring action"
is often not testable. It is certainly somewhat
subjective. I think
this has to be advisory, relying on the best judgment
of folks making
the tool.

With #6, we again have a lot of judgment calls
involved in templates -
how many of the templates, how much facilitation?
Things that are
"musts" need to be testable; I don't know how to test
this.

In a certain sense ALL of this stuff is to some
extent "subjective" and much of what we prescribe
isn't strictly "testable" but what I'm trying to get
across is that the "best judgement of folks making
the tool" has proved that it's somewhat like leaving
the foxes as security guards for the henhouse.

The main reason we have to go through these exercises
is that the "folks making the tool" have been at the
very least resistive (obstructive?) about providing
universal inclusion in the accessibility sense, else
there'd be no problem.

I clearly meant "forces" to be a draconian boundary
case of choices of wording but somehow a breakthrough
in this has to be sought or we will continue to have
"save as HTML" selections that lead to absurd
implementations.

Love.

From: Katie Haritos-Shea
Date: Thu, Jun 07 2007 12:40 PM
Subject: Re: Proposal on authoring tools

Concerning.........

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.

.......the tool should provide a certain minimum number of pre-coded accessible objects (ie, buttons, tables, templates, CSS files, form components) offered to the author to choose from first. (They would need to look farther to find in-accessible objects, or not find them at all, in a very good product).

Katie Haritos-Shea

-----Original Message-----
>From: Peter Korn < = EMAIL ADDRESS REMOVED = >
>Sent: Jun 7, 2007 12:48 PM
>To: TEITAC Web/Software Subcommittee < = EMAIL ADDRESS REMOVED = >
>Subject: Re: [teitac-websoftware] Proposal on authoring tools
>
>Hi William,
>
>> 4. For authoring tools with a user interface, authoring tools must provide a mode which prompts authors to create accessible content.
>>
>> Can't we get a bit stronger than "prompts"? Although I sort of lean towards "forces", there are other choices.
>>
>
>There is no way a tool can know that the information a user enters is
>the correct information (e.g. is the description of a graphic a useful
>one that makes the graphic accessible?). There are too many cases
>requiring judgment calls. Further, there are situations in which more
>information isn't helpful - it is sometimes quite appropriate to NOT
>enter information (e.g. obvious user interface elements only need a
>"name", not also a "description", and putting a lengthy and unnecessary
>description in that gets read by a screen reader can actually be a
>burden to people with disabilities).
>
>I think "forces" or something like it will actually generate problems in
>many situations.
>
>> 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.
>> 7. Authoring tools should give prominence to the most accessible authoring action for achieving an authoring outcome.
>>
>> both of the "shoulds" in these two ought to be stronger, say "must"?
>>
>
>One big concern with #7 is that the "most accessible authoring action"
>is often not testable. It is certainly somewhat subjective. I think
>this has to be advisory, relying on the best judgment of folks making
>the tool.
>
>With #6, we again have a lot of judgment calls involved in templates -
>how many of the templates, how much facilitation? Things that are
>"musts" need to be testable; I don't know how to test this.
>
>
>Regards,
>
>Peter Korn
>Accessibility Architect,
>Sun Microsystems, Inc.
>

From: Jan Richards
Date: Thu, Jun 07 2007 2:55 PM
Subject: Re: Proposal on authoring tools

Judy Brewer wrote:

> 3. Authoring tools must allow the author to augment
> automatically-generated content with accessibility information.

I wonder if this is sufficient.

In ATAG 2.0 the currently agreed-upon wording is Guideline B.1.3 "Ensure
automatically generated content is accessible".

The problem that this is designed to address is that automatic processes
can pump out LOTS of content and if accessibility is not taken into
account at generation-time (e.g. by doing things right that can be
automated or by asking for human input when necessary) is difficult for
humans to go back later and retrofit that content.

Note that the ATAG 2.0 provision does not apply if the author is
responsible for the automatic process ignoring accessibility. For
example if they:
- ignored warnings/prompts along the way
- set up the tool to work that way
- gave the tool inaccessible source content to convert

So I might propose this re-wording:

"3. Authoring tools must provide a mode in which any content that is
specified exclusively by the authoring tool must be accessible."


Cheers,
Jan

--
Jan Richards, M.Sc.
Interim Staff Contact, AUWG, WAI-W3C

User Interface Design Specialist
Adaptive Technology Resource Centre (ATRC)
Faculty of Information Studies
University of Toronto

Email: = EMAIL ADDRESS REMOVED =
Web: http://jan.atrc.utoronto.ca
Phone: 416-946-7060
Fax: 416-971-2896

From: Peter Korn
Date: Thu, Jun 07 2007 7:35 PM
Subject: Re: Proposal on authoring tools

Hi Sailesh,

>> 2. Authoring tools must, except by explicit user action, preserve
>> accessibility information necessary for meeting the electronic content
>> provisions.
>>
> On reading the statement I am not sure I understand "except by explicit
> user action, ". Does it mean:
> 2. Authoring tools must preserve accessibility information necessary for
> meeting the electronic content provisions unless the user explicitly
> indicates otherwise.
>

That was my understanding of this text during our "sub-team" discussions
of it.

>> 4. For authoring tools with a user interface, authoring tools must provide
>> a mode which prompts authors to create accessible content.
>>
> Is "For authoring tools with a user interface, ", required? For user driven
> authoring tools, a user interface is certainly needed and if it is an
> automated authoring tool, it should provide a programmable switch or
> parameter by which one can turn on / off this mode. So I think it
> should simply read:
> 4. Authoring tools must provide a mode which prompts authors to create
> accessible content.
>

I believe the "with a user interface" clause is required. Otherwise you
are essentially saying that the government cannot purchase any
unattended, automated tools that operate on content. Because then every
such tool "must provide a mode which prompts".

> 5. For authoring tools with a user interface, authoring tools must provide a
> mode which assists authors in checking for accessibility problems.
> Evaluation techniques may be very difficult to incorporate into authoring
> tools. Perhaps the guideline should state:
> User-driven authoring tools must provide a mode which assists authors in
> checking for accessibility problems directly or via a separate interface. I
> mean like a plug-in.
>

A key here is we don't (and frankly can't) mandate exactly what
assistance is provided. We have a vibrant industry of web accessibility
tools which appropriately compete on features and functionality. I read
this text as requiring some assistance, not that it be the most
comprehensive (compare to a word processor that checks for spelling, but
not for grammar, reading level, and assistance in removing 'rivers'
within formatted text).

Even so, I'm concerned with this being a "must" vs. a "should" - for the
very reason that it is so hard to test. And the fact that there is a
vibrant industry around this need for the web, and another growing for
PDF, and a third already coming together for ODF, further underscores
for me the fact that the well meaning content creator will likely use a
3rd party tool anyway...

> About #6 that requires accessibility enabled templates: Templates may be
> desirable and a tool that offers these may have an advantage over another.
> But I am not sure this should be a requirement. In fact I feel the same way
> about authoring tools directly providing the ability to evaluate
> accessibility.
> Admittedly templates and eval capability will help authors become more
> accessibility conscious and encourage development of accessible content, but
> is it a reasonable requirement? Some diagnostic capability could perhaps be
> incorporated directly but how thorough and effective can it get? Limited and
> haphazard evaluation capabilities may end up being a disservice to
> accessibility. The focus of authoring tools should be on ability to produce
> valid code while permitting users to incorporate all the accessibility
> features offered by the technology and ensuring the authoring interface is
> accessible.

Yes, you've said this better than I did - limited and haphazard
evaluation capabilities put in simply to minimally meet this requirement
may be a disservice. I think we do better to encourage competition
around this functionality.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

From: Peter Korn
Date: Thu, Jun 07 2007 7:40 PM
Subject: Re: Proposal on authoring tools

Hi Brad,

> I suggest the following as an additional requirement.
>
> For authoring tools with a user interface, authoring tools must provide
> a mode, or administrative option to require the use of accessibility
> features.
>

I don't understand this requirement. More specifically, I don't
understand what I would do to meet this requirement. Not every tool -
especially a tool in a collection of tools used to author content
together as a suite - will be capable of enabling the author to enter
every last piece of accessibility information, or take advantage of
every last accessibility feature in a content format. Further, in too
many cases the use of such features is subjective.

E.g. imagine a document with a form in it, with icons in the form.
Further imagine that one of the accessibility features of the document
content format is the ability to tag images with names *and* with
descriptions. In many cases the name will be sufficient information for
a blind user with their screen reader to understand the meaning.
Developers putting in lengthy descriptions only adds to the verbosity of
the screen reader user experience, and in fact can detract from
comprehension. A tool that forced authors to enter descriptions for
every user interface element where a description could be entered would
create a lot of extra work for the author that resulted in worse
accessibility in cases. And frankly, I would fear authors simply
entering "123" or " " in these situations just to get the *&% tool off
of their back. And that wouldn't serve anyone's interests.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Judy
> Brewer
> Sent: Thursday, June 07, 2007 1:32 AM
> To: = EMAIL ADDRESS REMOVED =
> Subject: [teitac-websoftware] Proposal on authoring tools
>
> The following proposal on authoring tools represents current work in
> progress by a small group following the recent TEITAC face-to-face
> meeting.
> Please add your comments as we continue to work on this, now on the
> Web/Software list. For those who already contributed in the small group,
> thank you for your input on the draft; the latest version here attempts
> to capture your most recent feedback in our discussion, but please
> continue to help refine this on the Web software list now.
>
> 1. Authoring tools must have the ability to produce content which passes
> the electronic content provisions.
>
> 2. Authoring tools must, except by explicit user action, preserve
> accessibility information necessary for meeting the electronic content
> provisions.
>
> 3. Authoring tools must allow the author to augment
> automatically-generated content with accessibility information.
>
> 4. For authoring tools with a user interface, authoring tools must
> provide a mode which prompts authors to create accessible content.
>
> 5. For authoring tools with a user interface, authoring tools must
> provide a mode which assists authors in checking for accessibility
> problems.
>
> 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.
>
> 7. Authoring tools should give prominence to the most accessible
> authoring action for achieving an authoring outcome.
>
> Regards,
>
> - Judy
>
>
>

From: Sailesh Panchang
Date: Fri, Jun 08 2007 7:10 AM
Subject: Re: Proposal on authoring tools

Refer: 4. For authoring tools with a user interface, authoring tools must
provide a mode which prompts authors to create accessible content.
Peter wrote:
>I believe the "with a user interface" clause is required. Otherwise you
>are essentially saying that the government cannot purchase any unattended,
>automated tools that operate on content. Because then every such tool
>"must provide a mode which prompts".

Peter, that is my point. I am raising the bar and saying that an automated
tool too should have some programmable switch or mechanism by which one can
turn on / off generation of accessible content. Maybe "prompts" is not the
right word because it does suggest that it will have a UI. The statement
needs to be re-worded in case the concept is acceptable.
Sailesh Panchang
Senior Accessibility Engineer
Deque Systems Inc. (www.deque.com)
11130 Sunrise Valley Drive, Suite #140,
Reston VA 20191
Phone: 703-225-0380 (ext 105)
E-mail: = EMAIL ADDRESS REMOVED =

From: David Poehlman
Date: Fri, Jun 08 2007 8:50 AM
Subject: Re: Proposal on authoring tools

I wonder why we don't just require them to produce accessible content and
prompt where there are ambiguities as to how to address them.

----- Original Message -----
From: "Sailesh Panchang" < = EMAIL ADDRESS REMOVED = >
To: < = EMAIL ADDRESS REMOVED = >; "'TEITAC Web/Software Subcommittee'"
< = EMAIL ADDRESS REMOVED = >
Sent: Friday, June 08, 2007 9:10 AM
Subject: Re: [teitac-websoftware] Proposal on authoring tools


Refer: 4. For authoring tools with a user interface, authoring tools must
provide a mode which prompts authors to create accessible content.
Peter wrote:
>I believe the "with a user interface" clause is required. Otherwise you
>are essentially saying that the government cannot purchase any unattended,
>automated tools that operate on content. Because then every such tool
>"must provide a mode which prompts".

Peter, that is my point. I am raising the bar and saying that an automated
tool too should have some programmable switch or mechanism by which one can
turn on / off generation of accessible content. Maybe "prompts" is not the
right word because it does suggest that it will have a UI. The statement
needs to be re-worded in case the concept is acceptable.
Sailesh Panchang
Senior Accessibility Engineer
Deque Systems Inc. (www.deque.com)
11130 Sunrise Valley Drive, Suite #140,
Reston VA 20191
Phone: 703-225-0380 (ext 105)
E-mail: = EMAIL ADDRESS REMOVED =

From: Sean Hayes
Date: Fri, Jun 08 2007 8:55 AM
Subject: Re: Proposal on authoring tools

You can't require a prompt in a tool which has to run unattended. We may be able to craft language around options which create a specific mode of operation though.

Sean Hayes
Standards and Policy Team
Corporate Accessibility Group
Microsoft
Phone:
mob +44 7977 455002
office +44 117 9719730

From: Peter Wallack
Date: Fri, Jun 08 2007 10:40 AM
Subject: Re: Proposal on authoring tools

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I too question why are we are singling out 'authoring tools with a UI'.
Why not require that&nbsp; a product that operates unattended or as an API
return "failure" when the data sent to it is insufficient or ambiguous
in terms of its ability to return an accessible result. I suppose it
could optionally offer an interactive mode to help remedy the
situation, but I wouldn't suggest requiring that.<br>
<pre class="moz-signature" cols="72">Peter Wallack
Accessibility Program Director
Oracle Corporation</pre>
<br>
<br>
David Poehlman wrote:
<blockquote cite="mid:001301c7a9db$3ac13120$0901a8c0@HANDS" type="cite">
<pre wrap="">I wonder why we don't just require them to produce accessible content and
prompt where there are ambiguities as to how to address them.

----- Original Message -----
From: "Sailesh Panchang" <a class="moz-txt-link-rfc2396E" href="mailto: = EMAIL ADDRESS REMOVED = ">&lt; = EMAIL ADDRESS REMOVED = &gt;</a>
To: <a class="moz-txt-link-rfc2396E" href="mailto: = EMAIL ADDRESS REMOVED = ">&lt; = EMAIL ADDRESS REMOVED = &gt;</a>; "'TEITAC Web/Software Subcommittee'"
<a class="moz-txt-link-rfc2396E" href="mailto: = EMAIL ADDRESS REMOVED = ">&lt; = EMAIL ADDRESS REMOVED = &gt;</a>
Sent: Friday, June 08, 2007 9:10 AM
Subject: Re: [teitac-websoftware] Proposal on authoring tools


Refer: 4. For authoring tools with a user interface, authoring tools must
provide a mode which prompts authors to create accessible content.
Peter wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I believe the "with a user interface" clause is required. Otherwise you
are essentially saying that the government cannot purchase any unattended,
automated tools that operate on content. Because then every such tool
"must provide a mode which prompts".
</pre>
</blockquote>
<pre wrap=""><!---->
Peter, that is my point. I am raising the bar and saying that an automated
tool too should have some programmable switch or mechanism by which one can
turn on / off generation of accessible content. Maybe "prompts" is not the
right word because it does suggest that it will have a UI. The statement
needs to be re-worded in case the concept is acceptable.
Sailesh Panchang
Senior Accessibility Engineer
Deque Systems Inc. (<a class="moz-txt-link-abbreviated" href="http://www.deque.com">www.deque.com</a>)
11130 Sunrise Valley Drive, Suite #140,
Reston VA 20191
Phone: 703-225-0380 (ext 105)
E-mail: <a class="moz-txt-link-abbreviated" href="mailto: = EMAIL ADDRESS REMOVED = "> = EMAIL ADDRESS REMOVED = </a>

From: Walser, Kate
Date: Fri, Jun 08 2007 12:00 PM
Subject: Re: Proposal on authoring tools

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

From: David Poehlman
Date: Fri, Jun 08 2007 1:25 PM
Subject: Re: Proposal on authoring tools

four is needed because some unconciencious sould will not go back and check
for compliance after the job is done. It does say provide a mode though so
presumably, one does not have to use that mode.

Five is there because we already have spelling, syntax and grammar checking
and we can get standalone tools for them as well. It is also there because
accessibility or in this case, standards compliance which it is hoped will
lead to accessability is just as important a part of the whole package as is
looking and smelling good.

six I agree with you on. I believe preauthored means something like you
describe in that someone started but did not finish it.

In your response to #7, you raise the issue of alternative text vs alt and
title. alternative means alternative, title is title or something perhaps
more annotative. if it is alternative text, it's an alt tag. I agree
though that as I read it, seven is a slipery slope.

----- Original Message -----
From: "Walser, Kate" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC Web/Software Subcommittee" < = EMAIL ADDRESS REMOVED = >
Sent: Friday, June 08, 2007 1:15 PM
Subject: Re: [teitac-websoftware] Proposal on authoring tools


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

From: Hoffman, Allen
Date: Mon, Jun 11 2007 7:40 AM
Subject: Re: Proposal on authoring tools

Hi:

I like the definition as long as we can expand it to include non-web
content. More explanatory information about this allowance of
completely separated non-integrated components will need to be provided
or it will appear very untestable, and even very difficult for a
developer/manufacturer to represent their compliance.




Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Dana
Simberkoff
Sent: Monday, June 11, 2007 9:33 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Proposal on authoring tools

Kate-

In regards to your comment number 5 below- My understanding is that ATAG
2.0 defines an "authoring tool" as any software, or collection of
software components, that authors use to create or modify Web content
for publication.

Additionally- collection of software components Any software products
used together (e.g., base tool and plug-in) or separately (e.g., markup
editor, image editor, and validation tool), regardless of whether there
has been any formal collaboration between the developers of the
products.

Does that address this question?

Thanks-
Dana


Dana Louise Simberkoff
(o) 603-578-1870 x11
(c) 603-496-0359



-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Walser,
Kate
Sent: Friday, June 08, 2007 1:15 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Proposal on authoring tools

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

From: Dana Simberkoff
Date: Mon, Jun 11 2007 7:45 AM
Subject: Re: Proposal on authoring tools

Kate-

In regards to your comment number 5 below- My understanding is that ATAG
2.0 defines an "authoring tool" as any software, or collection of
software components, that authors use to create or modify Web content
for publication.

Additionally- collection of software components Any software products
used together (e.g., base tool and plug-in) or separately (e.g., markup
editor, image editor, and validation tool), regardless of whether there
has been any formal collaboration between the developers of the
products.

Does that address this question?

Thanks-
Dana


Dana Louise Simberkoff
(o) 603-578-1870 x11
(c) 603-496-0359



-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Walser,
Kate
Sent: Friday, June 08, 2007 1:15 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Proposal on authoring tools

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

From: Walser, Kate
Date: Tue, Jun 12 2007 12:20 PM
Subject: Re: Proposal on authoring tools

With respect to proposed Authoring Tool guideline #5 (authoring tools
must include a mode to check for accessibility problems),
Kate Walser asked if implementing guideline #5 would prohibit new tool
development given patented accessibility-checking capabilities on the
market today.
Dana Simberkoff replied that ATAG 2.0 defines "authoring tool" as
software or a collection of software components, so any products used
together (e.g., base tool and plug-in) or separately (e.g., markup
editor, image editor, validation tool) count whether there's formal
collaboration between product developers.

Kate replies: Thanks, Dana. That answers one question.
The next question ties back to evaluating competing products in light of
a potential guideline #5. How would this standard be evaluated by an
agency looking to purchase an authoring tool, if the agency already has
purchased an accessibility-checking tool?
Example: Agency X issues a solicitation that requests technical and cost
information about an authoring tool that will enable Agency X to
implement a goal. Let's say it's implementing a new Web site in this
example.
Company A decides to respond and has an authoring tool that includes
accessibility-checking capabilities, which they've licensed from Company
C.
Company B responds as well and has a different authoring tool. Their
tool does not incorporate accessibility-checking capabilities. In fact,
Company B doesn't even care about this provision as they expect agencies
will have their own tools.
When Agency X evaluates Company A and B's responses, aside from the new
guideline #5, all else is equal. Company A better meets the criteria,
but Company B meets the rest of the criteria and the agency already has
the accessibility checking tool. Plus Company B's tool is cheaper.

So it seems like Company B could win out given best value and agency
ownership of the tool already though Company A has worked harder to
follow the standards and may have been doing so for years (e.g., let's
say they'd built in the accessibility checking feature when the original
508 was out).

Is this a realistic scenario? If not, I'll be silent. Am just concerned
that with guideline #5, using "must" creates issues and using "should"
creates even more and makes it difficult for an agency to evaluate
products.

Thanks!
Kate

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

From: Hoffman, Allen
Date: Tue, Jun 12 2007 12:30 PM
Subject: Re: Proposal on authoring tools

It is very realistic.
However, that is why "best meets" agency needs is in the current law, to
allow for variations on the business needs and selection criteria.



Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Walser,
Kate
Sent: Tuesday, June 12, 2007 2:19 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Proposal on authoring tools

With respect to proposed Authoring Tool guideline #5 (authoring tools
must include a mode to check for accessibility problems), Kate Walser
asked if implementing guideline #5 would prohibit new tool development
given patented accessibility-checking capabilities on the market today.
Dana Simberkoff replied that ATAG 2.0 defines "authoring tool" as
software or a collection of software components, so any products used
together (e.g., base tool and plug-in) or separately (e.g., markup
editor, image editor, validation tool) count whether there's formal
collaboration between product developers.

Kate replies: Thanks, Dana. That answers one question.
The next question ties back to evaluating competing products in light of
a potential guideline #5. How would this standard be evaluated by an
agency looking to purchase an authoring tool, if the agency already has
purchased an accessibility-checking tool?
Example: Agency X issues a solicitation that requests technical and cost
information about an authoring tool that will enable Agency X to
implement a goal. Let's say it's implementing a new Web site in this
example.
Company A decides to respond and has an authoring tool that includes
accessibility-checking capabilities, which they've licensed from Company
C.
Company B responds as well and has a different authoring tool. Their
tool does not incorporate accessibility-checking capabilities. In fact,
Company B doesn't even care about this provision as they expect agencies
will have their own tools.
When Agency X evaluates Company A and B's responses, aside from the new
guideline #5, all else is equal. Company A better meets the criteria,
but Company B meets the rest of the criteria and the agency already has
the accessibility checking tool. Plus Company B's tool is cheaper.

So it seems like Company B could win out given best value and agency
ownership of the tool already though Company A has worked harder to
follow the standards and may have been doing so for years (e.g., let's
say they'd built in the accessibility checking feature when the original
508 was out).

Is this a realistic scenario? If not, I'll be silent. Am just concerned
that with guideline #5, using "must" creates issues and using "should"
creates even more and makes it difficult for an agency to evaluate
products.

Thanks!
Kate

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