Thread Subject: Re: Authoring Tools -- Wiki section added

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: Hoffman, Allen
Date: Wed, Jul 25 2007 3:25 PM

Norman Robinson wrote:
a. What is the definition for "accessible content formats"?


An accessible content format is one that meets the requirements
identified in the new "content formats" section of the proposed
standards. So, for example, if OOXML was proposed, it would need to
meet the requirements identified in that section for the functions it
supports in that format.

Norman wrote:
b. Content is not currently covered in the existing provisions.
How might content be referenced in the next revision? As a file format?


Peter Korn wrote:
Thus we have content accessibility guidelines, including specific HTML
content accessibility guidelines. These apply to HTML content whether
they are viewed via an HTTP GET request from a website, or a File->Open
command within a web browser from a local/networked disk, or within a
Help browser, or from a word processor.

Likewise, we have application accessibility guidelines, perhaps
including specifically guidelines for applications that are a blend of
HTML/SVG/whatever and running code (be that code Flash or Java or
ActiveX or whatever).


There are significant challenges with this view of things, most
especially including harmonization challenges and the existing &
historical view/language around "Web accessibility". But increasingly,
making distinctions about where a thing comes from is making less and
less sense.

Allen continues:
1. Define accessibility requirements for formats. Without the ability
to store appropriate information and the specific accessibility
attributes, a format can not be made accessible by the author,
user-agent, and in many circumstances, by the assistive technology.
1a. Require that the most accessible content format is used.
2. Establish that "all content" must be made compliant via the
accessibility features the format supports.
3. provide specific requirements for "web" content since we know
specific mechanisms
that must be employed to meet accessibility needs for this area.
3a. provide specific requirements for "multimedia" since these area
already known.
4. provide software requirements since we know specific requirements
for this area.
4a. provide authoring tool requirements to improve authors ability to
use the accessibility attributes in the format when available.
4b. provide "platform" requirements to ensure that accessibility
attributes from content are able to be represented in a programatic
fashion.
4c. provide user-agent requirements to ensure that the accessibility
attributes of content are rendered with all appropriate options, and to
alleviate some authoring burden when some accessibility options can be
made at the user-agent phase of the delivery chain. Hypothetical
example of this is the W3C 2 level AA requirement to address blinking
after 3 seconds. If this is implemented as a content requirement all
authors and testers will need to start authoring and testing for this
requirement, but if implemented as a user-agent requirement, a smaller
group of people will have to address this problem with a solution.

Norman wrote:
a. What is the complete definition of "accessibility
information"?

Allen responds:
"accessibility information" includes the set of attributes or encoding
that makes the content meet the requirements for that format. For
example, if a format allows for insertion of images in to a document,
and has the alternate text function, that would be accessibility
information. if it also allows tables to be marked up for header/cell
association, then that would also be in that set of attributes. So, at
the end of the day the author would be bound by the functionality of the
format--which is true under any condition already.

Norman wrote:
b. If the user indicates they do not want accessibility
information does that then imply we could still have compliant content?

Allen responds:
not specifically. but, this arose from the situation where someone is
working on a draft and just wants to get the work in to some shape to
then finalize. In this situation they may not feel it appropriate to
put alt-text on images, mark up tables, set headers, etc--but can do so
at final publication time. There may be better more precise language
for this situation we can craft--any proposal?

Norman writes:
a. What are authoring tools without a user interface? Bash shell
scripts?
b. Isn't this redundant with the first (#1) statement?

Allen responds:
first, authoring tools without user-interfaces might be transparent
items in the work flow. Shell scripts are good! Second, maybe, but
more precise to such non-interface tools.






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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
Robinson, Norman B - Washington, DC
Sent: Wednesday, July 25, 2007 2:38 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki section added

Regarding "[teitac-websoftware] Authoring Tools -- Wiki section added",
it was asked for any specific remaining concerns for discussion -- in
which case also suggestions for how to resolve those concerns?

Playing devil's advocate on the Authoring Tool proposed provisions:

1. For each accessible content format supported, authoring tools
must allow the author to produce content, including content derived from

programmatic sources, that meets applicable electronic content
accessibility standards.

a. What is the definition for "accessible content formats"?
b. Content is not currently covered in the existing provisions.
How might content be referenced in the next revision? As a file format?
If file formats are not covered, how will this work?

2. Authoring tools must preserve accessibility information necessary
for meeting the electronic content provisions, unless the user
explicitly indicates otherwise.

a. What is the complete definition of "accessibility
information"?
b. If the user indicates they do not want accessibility
information does that then imply we could still have compliant content?

3. For authoring tools with a user interface, authoring tools must
provide a mode which prompts authors to create accessible content; and
either a mode which assists authors in checking for accessibility
problems, or interoperability with evaluation tools that provide that
function.

a. What are authoring tools without a user interface? Bash shell
scripts?
b. Isn't this redundant with the first (#1) statement?

4. Authoring tools which provide pre-authored content, or templates
to facilitate production of content, must provide at least one version
that meets applicable electronic content accessibility standards.

a. What happens when the content doesn't have an accessible
version? Think of Flash 1.0.
b. Again, per statement #1 question (b), content is not
currently covered in the existing provisions. Is content the same as a
file format? If file formats are not in the revision, how will this
work?

Finally, questions about the goals regarding authoring tools:
how is software called "authoring tools" any different from any other
software under the Section 508 provisions? Why can't we simply apply the
Section 508 technical software standards to "authoring tools"? How are
we to get away from the logic trap that we are mandating specific
features in software of type "authoring tools?". Do we do that for any
other particular type of software? Does this only apply to *web based
content*? How can the be misused? (e.g., If I use Notepad or Bash Shell
as an authoring tool, does this really apply?

My suggestion for resolving these concerns:
1. Remove the section on authoring tools. Rationale is they are
no different than any other software!
2. Define "accessible content formats" or "file formats"
required for accessibility in the refresh.
3. Address *validation* and *well-formed* in the new "file
formats" section of the refresh.

Regards,


Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246

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