Thread Subject: Re:
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: Katie Haritos-Shea
Date: Mon, Jun 18 2007 1:48 PM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Tom Brett: "Hardware Labels/LCD Windows"
- Previous message in thread: Hoffman, Allen: "Re:"
- Messages sorted by: Author | Thread | Date
Allen,
I think that this is a very important (perhaps *most* important) provision to be added.
I see the dilemma. Hmmm....
First thought, in answer to your question on where/how to insert it is, certainly choice A or B. It needs to be an overarching requirement. Second thought, I lean towards B because I think that this is a Technical Requirement.
Katie Haritos-Shea
-----Original Message-----
>From: "Hoffman, Allen" < = EMAIL ADDRESS REMOVED = >
>Sent: Jun 12, 2007 3:36 PM
>To: Katie Haritos-Shea < = EMAIL ADDRESS REMOVED = >, TEITAC Web/Software Subcommittee < = EMAIL ADDRESS REMOVED = >
>Subject: RE: [teitac-content accessibility general
>
>All:
>
>I have been wrestling a proposal in to shape for a while now but am
>really running out of time.
>
>Let me describe what I'm after, describe the three ways I think we can
>get there, and ask for your help in planning the best way to present
>recommendations for the final 06/30 draft TEITAC.
>
>
>When the TEITAC was initiated by the US Access-Board the Board included
>a theme regarding applicability of the EIT accessibility standards to
>electronic content as a whole. This applicability question has been a
>continuing challenge for Federal and industry partners alike since the
>standards were adopted. Often CFR1194.22(a-p) standards are applied to
>electronic content encoded in other than HTML or "mark up" based
>formats, and because of this they often are not easily scoped to all
>format situations. For example in CFR1194.22(e), "server-side image
>maps shall not be used accept where geometric shapes can not be
>represented", is specifically connected to the <ismap> HTML tag of that
>content format. When it is applied to other formats, such as the widely
>used Microsoft Office format, it is just not easily transferable, and
>causes confusion and a wide variety of requirements to be presented both
>to industry and Federal employees alike. Questions arose about if
>electronic content NOT transported by the HTTP or HTTPS protocols, for
>the "web", were covered by the standards. Even an HTML document sent
>via email might not be covered in the email, but may be if placed on a
>web site and accessed as part of a web-based email service.
>
>To address this problem several additions to the standards are needed.
>First, minimum accessibility standards for formats are required to
>eliminate formats which by their inability to store sufficient
>information AND accessibility attributes can not be authored to be
>accessible. Second, either the standards for web must be broadened to
>more directly address a wider set of electronic content formats, or a
>broadly scoped standard must be developed to require that the
>accessibility attributes of a format are to be used when available, and
>that accessible formats MUST be used. Broadening the existing
>CFR1194.22 standards may reduce their effectiveness in addressing this
>large area of electronic content, so could be a step backwards,
>Broadening the CFR1194.22 "web" standards would also present multiple
>standards for web developers which goes against the general theme of
>harmonizing with the W3C WAI and other standards bodies. Developing an
>adequately scoped standard that is effective in directing that
>electronic content is produced in accessible formats and with sufficient
>accessibility attributes is also a challenge but may be the most direct
>path to fully clarifying how accessibility is to be achieved for
>electronic content. Third, if the standards are re-organized so that
>standards for electronic content are provided with HTML and other
>mark-up based formats as a subset of those standards, this applicability
>challenge can be addressed in a logical, and effective fashion.
>
>I have been working to pull together all the standards that would apply
>to "content" as a whole, and then insert as subsets the standards that
>fall for web-only, software only, etc. I'm just having a slow go of it
>with the WIKI and a screen reader.
>
>i propose a provision, possibly in information/documentation/support or
>at the top of the proposed content format accessibility stqandards
>section that says:
>
>Electronic content shall be provided in at least one format that meets
>minimum format accessibility standards, and shall be authored to be
>accessible using the accessibility functionalities of that format, and
>MUST meet technical provisions (list), and functional performance
>criteria from subpart C.
>
>The rationale for such a statement is that while we may include format
>standards, right now "content" standards are primarily for the web.
>Some have mentioned that the "web" standards are not specifically for
>the web, but they have tradditionally been interpreted this way, and
>their current title includes intra and internet information and
>applications. The web standards as they are known are probably the most
>successful set of standards of the current set, so broadening them to
>address content in general may not get us what we want.
>
>Below please find the draft authoring tool standards which are part of
>this equation. I think several of these should and can be comtined, but
>the point for these is that authors need consistent help and guidance to
>allow them to produce accessible content, or content which meets
>accessibility standards via the accessibility functionalities the
>storeage format includes.
>
>>
>>1. Authoring tools must have the ability to produce content which
>>passes the electronic content provisions.
>Note: we have inter/intranet information and application provisions only
>now.
>>
>>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.
>>
>I think 4, 5, and 7 can be integrated successfully without losing
>meaning, but we can discuss the requirements individually until we come
>to final consensus.
>
>So, three ways I propose we solve this are:
>
>1. Add the proposed provision above to information documentation and
>support to say electronic content must be provided in at least one
>accessible format, and must be authored to meet technical standards and
>functional performande criteria, using the available accessibility
>functionalities of the format. Include minimum format accessibility
>standards.
>
>2. Broaden the provisions in current CFR 1194.22 so they can be
>applicable to "any" electronic content that includes specific kinds of
>functionality such as tables, frmaes, images, etc. include minimum
>format accessibility standards. No need to explicitly require
>electronic meet broadened cfr1194.22 standards as they are broad enough
>now. Note, this approach won't say that such content must be in an
>accessible format however.
>
>3. (the hard way). For each minimum accessibility format standard,
>include language to say that electronic content that includes that
>functionality and attributes must meet the standard. Basically wrap it
>all in one set. hard to do effectively.
>
>
>
>
>
>
* katie *
Katie Haritos-Shea
Section 508 Technical Policy Analyst
703-371-5545
People may forget exactly what it was that you said or did,
but people will never forget how you made them feel.......
- Next message in Thread: Tom Brett: "Hardware Labels/LCD Windows"
- Previous message in Thread: Hoffman, Allen: "Re:"