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: Gregg Vanderheiden
Date: Wed, Jul 25 2007 7:30 PM

I don't think meeting the content format provisions alone makes something
accessible.

It might 'meet accessibility standards' but to be accessible it has to
actually be useable. You must then ask - accessible to who?

Also - one of they key links is the existence of AT that can work with the
technology format.

Assume I create a new document format called the Gregorian Document Format
(GDF). I create the format such that it meets all of the document format
provisions. However, I failed to work with AT vendors (why should I - it
will be labeled accessible if I meet the standard) and as a result there are
no AT that will work with GDF. Should it be called accessible anyway?
Should we be posting information on social security benefits in this
technology? It is 'accessible' after all. The only problem is that no AT
users can access it.

Hence I think we should be careful here.

1) we should never call things accessible just because they meet the our
standard. Think of cognitive to prove this.

2) we should not think of things as 'meeting our guidelines' via 'at
support" but rather through "AT". That is, there has to actually be AT that
supports it and users have to have access to it -- or they will not be able
to 'access' the E&IT.

This of course also applies to the doc formats. They should be worded such
that 'programmatically determinable' means that is can be determined using
real AT and not just has the potential to be accessible via software.




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



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Hoffman, Allen
> Sent: Wednesday, July 25, 2007 4:18 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Authoring Tools -- Wiki
> section added
>
> 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