Thread Subject: Group B: 22(k) Text-only page

Return to this mailing list's archives

From: Andi Snow-Weaver
Date: Tue, Nov 14 2006 4:40 PM
Subject: Group B: 22(k) Text-only page

Current 508 wording:

22(k) A text-only page, with equivalent information or functionality, shall
be provided to make a web site comply with the provisions of this part,
when compliance cannot be accomplished in any other way. The content of the
text-only page shall be updated whenever the primary page changes.

WCAG 2.0 allows for alternate versions of the content but does not require
that they be "text-only". But WCAG 2.0 does contain the additional
restriction that the versions must be available from the same URI:
"Alternate Versions-L1: At least one version of the content meets all Level
1 success criteria, but alternate version(s) that do not meet all Level 1
success criteria may be available from the same URI."

Andi

From: Andi Snow-Weaver
Date: Tue, Nov 14 2006 4:40 PM
Subject: Re: Group B:

Allen,

The ISO standard is obviously newer since it was just published as a draft
international standard this year. Balloting closes soon on it I think.

I agree that we don't need to change 508 just to harmonize with an
international standard unless there is an issue with it as currently
written. There may be issues though with 508 provisions that are more
restrictive than the ISO standard. That may in fact be why the ISO standard
is more permissive. We have a lot more experience now than we did five
years ago.

Andi

From: Hoffman, Allen
Date: Wed, Nov 15 2006 6:05 AM
Subject: Re: Group B:

Just a couple more thoughts on harmonizing.

My experience to date is that I have not seen any other standards than
W3cC/WAI mentioned regarding accessibility for web destined for the
government. I am not seeing the developer confusion for anyone in the
market now. this doesn't mean, for example, large corporations, or
small ones, who are developing web items for international distribution
don't need these additional standards. I have never seen alternates to
508 standards for software in any documentation or proposals for the
government, or for that matter, even statements of work. I'm not
throwing this in to poor water on the harmonizing effort, as it is only
the sensible thing to do--develop to common standards and save time and
improve items for use, but for us the Federal customers, 508 is supreme
in the accessibility requirements world.

Allen Hoffman
Department of Homeland Security
Office on Accessible Systems & Technology

From: Andrew Kirkpatrick
Date: Wed, Nov 15 2006 11:20 AM
Subject: Re: Group B: 22(k) Text-only page

It seems odd that the web section has its own functional equivalence
exception. Do we need this?

AWK

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Andi Snow-Weaver
> Sent: Tuesday, November 14, 2006 6:31 PM
> To: = EMAIL ADDRESS REMOVED =
> Subject: [teitac-websoftware] Group B: 22(k) Text-only page
>
>
> Current 508 wording:
>
> 22(k) A text-only page, with equivalent information or
> functionality, shall be provided to make a web site comply
> with the provisions of this part, when compliance cannot be
> accomplished in any other way. The content of the text-only
> page shall be updated whenever the primary page changes.
>
> WCAG 2.0 allows for alternate versions of the content but
> does not require that they be "text-only". But WCAG 2.0 does
> contain the additional restriction that the versions must be
> available from the same URI:
> "Alternate Versions-L1: At least one version of the content
> meets all Level
> 1 success criteria, but alternate version(s) that do not meet
> all Level 1 success criteria may be available from the same URI."
>
> Andi
>
>

From: Hoffman, Allen
Date: Wed, Nov 15 2006 11:55 AM
Subject: Re: Group B: 22(k) Text-only page

In reference to CFR1194.22K, Andrew Kirkpatrick wrote:
"It seems odd that the web section has its own functional equivalence
exception. Do we need this?"

Background from my recollection:
The idea was very prevalent several years back, just create a "text
equivalent" page. this was often for supporting users of the text-mode
Lynx browser. It was often also applied when pages were produced from
database outputs, or templates, as creation of the alternatives either
had to be done via alternate templates using same data sources, or from
revised coding. This provision is really a reflection of the
state-of-the-art back then. The synchronizing requirements in the
provision reflect that problem of supporting two sets of web pages.

I feel this provision could be dropped, as it implies any tester "know"
what was doable in the development/implementation phase. it would, for
example, require anyone claiming this provision to document the logical
rationale for following this path, when in fact, they could just
indicate they meet the other provisions by equivalent facilitation.

This also leaves some people with the strange concept that text-only
alternatives to applications that retain "some" functionality are
acceptable, when generally they make little, or no sense to deploy. Why
would one want to maintain a graphical version of a web that is
functionally equivalent to a text-version? Creating such an alternate
version is often more work than just creating one that works in one
piece.

I think this really is allowing in a more directed way, usage of
equivalent facilitation.

Bottom line for me:
I think it can be dropped.

Allen Hoffman
Department of Homeland Security Office on Accessible Systems &
Technology

From: Gregg Vanderheiden
Date: Wed, Nov 15 2006 12:00 PM
Subject: Re: Group B: 22(k) Text-only page

In wcag we are in the process of moving this provision out of the
"provisions" and into the conformance section. So that would exactly
parallel what is being discussed here.


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



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Hoffman, Allen
> Sent: Wednesday, November 15, 2006 12:02 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Group B: 22(k) Text-only page
>
> In reference to CFR1194.22K, Andrew Kirkpatrick wrote:
> "It seems odd that the web section has its own functional
> equivalence exception. Do we need this?"
>
> Background from my recollection:
> The idea was very prevalent several years back, just create a
> "text equivalent" page. this was often for supporting users
> of the text-mode Lynx browser. It was often also applied
> when pages were produced from database outputs, or templates,
> as creation of the alternatives either had to be done via
> alternate templates using same data sources, or from revised
> coding. This provision is really a reflection of the
> state-of-the-art back then. The synchronizing requirements
> in the provision reflect that problem of supporting two sets
> of web pages.
>
> I feel this provision could be dropped, as it implies any
> tester "know"
> what was doable in the development/implementation phase. it
> would, for example, require anyone claiming this provision to
> document the logical rationale for following this path, when
> in fact, they could just indicate they meet the other
> provisions by equivalent facilitation.
>
> This also leaves some people with the strange concept that
> text-only alternatives to applications that retain "some"
> functionality are acceptable, when generally they make
> little, or no sense to deploy. Why would one want to
> maintain a graphical version of a web that is functionally
> equivalent to a text-version? Creating such an alternate
> version is often more work than just creating one that works
> in one piece.
>
> I think this really is allowing in a more directed way, usage
> of equivalent facilitation.
>
> Bottom line for me:
> I think it can be dropped.
>
> Allen Hoffman
> Department of Homeland Security Office on Accessible Systems
> & Technology

From: John M Slatin
Date: Wed, Nov 15 2006 12:15 PM
Subject: Re: Group B: 22(k) Text-only page

Don Barrett wrote:
I think we still need it in those cases where a new technology just
can't be made conformant. If we don't have this, then commercial
nonavailability could kick in and the page might go up as is; at least
with this standard, we require a text-only version, which is not
required by commercial nonavailability.

I don't quite understand this argument. If the new technology can't be
made conformant, it shouldn't be used, or else an alternative version
that does conform should be provided. Text-only is OK for users who are
blind, but it's no help at all to users with dyslexia, for example,
unless the text is also written for a high degree of readability.

It seems to me that vendors interested in having their technologies used
in sites and applications that have to meet 508 should also be
interested in using the appropriate APIs and doing other work necessary
tfor the technologies to conform.



"Good design is accessible design"
John Slatin, Director
Accessibility Institute University of Texas at Austin 1 University
station Stop G9600
Austin, TX 78712, USA
Phone +1.512.495.4288 Fax +1.512.495.4524 cell +1.512.784.7533
email = EMAIL ADDRESS REMOVED =
www.utexas.edu/research/accessibility/

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
Barrett, Don
Sent: Wednesday, November 15, 2006 12:08 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Group B: 22(k) Text-only page


"In reference to CFR1194.22K, Andrew Kirkpatrick wrote:
"It seems odd that the web section has its own functional equivalence
exception. Do we need this?"

I think we still need it in those cases where a new technology just
can't be made conformant. If we don't have this, then commercial
nonavailability could kick in and the page might go up as is; at least
with this standard, we require a text-only version, which is not
required by commercial nonavailability.

From: Barrett, Don
Date: Wed, Nov 15 2006 12:30 PM
Subject: Re: Group B: 22(k) Text-only page

"In reference to CFR1194.22K, Andrew Kirkpatrick wrote:
"It seems odd that the web section has its own functional equivalence
exception. Do we need this?"

I think we still need it in those cases where a new technology just
can't be made conformant. If we don't have this, then commercial
nonavailability could kick in and the page might go up as is; at least
with this standard, we require a text-only version, which is not
required by commercial nonavailability.

From: Barrett, Don
Date: Wed, Nov 15 2006 12:35 PM
Subject: Re: Group B: 22(k) Text-only page

The Blackberry is a perfect example of how commercial nonavailability
can stop 508 in its tracks. People use inaccessible technology all the
time in the name of nonavailability; it's awful but it happens. At
least with the text-only standard, you get something out of it.

From: Andrew Kirkpatrick
Date: Wed, Nov 15 2006 12:45 PM
Subject: Re: Group B: 22(k) Text-only page

Don - do you feel that if this standard was not around that developers
wouldn't know that if they can't meet the subpart 22 standards that they
need to figure out a different or additional way and to claim functional
equivalence?
AWK

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Barrett, Don
> Sent: Wednesday, November 15, 2006 2:33 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Group B: 22(k) Text-only page
>
> The Blackberry is a perfect example of how commercial
> nonavailability can stop 508 in its tracks. People use
> inaccessible technology all the time in the name of
> nonavailability; it's awful but it happens. At least with
> the text-only standard, you get something out of it.
>

From: Fratkin, Mike
Date: Wed, Nov 15 2006 12:55 PM
Subject: Re: Group B: 22(k) Text-only page

After the first year of Section 508, I have not seen a single instance
of text only pages used to meet compliance.

Mike


Don - do you feel that if this standard was not around that developers
wouldn't know that if they can't meet the subpart 22 standards that they
need to figure out a different or additional way and to claim functional
equivalence?
AWK

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Barrett, Don
> Sent: Wednesday, November 15, 2006 2:33 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Group B: 22(k) Text-only page
>
> The Blackberry is a perfect example of how commercial nonavailability
> can stop 508 in its tracks. People use inaccessible technology all
> the time in the name of nonavailability; it's awful but it happens.
> At least with the text-only standard, you get something out of it.
>

From: John M Slatin
Date: Wed, Nov 15 2006 1:10 PM
Subject: Re: Group B: 22(k) Text-only page

I agree that having an HTML version is nice. But I don't think of "HTML"
as equivalent to "text-only," since HTML supports all sorts of non-text
content.

John

"Good design is accessible design"
John Slatin, Director
Accessibility Institute University of Texas at Austin 1 University
station Stop G9600
Austin, TX 78712, USA
Phone +1.512.495.4288 Fax +1.512.495.4524 cell +1.512.784.7533
email = EMAIL ADDRESS REMOVED =
www.utexas.edu/research/accessibility/

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
Barrett, Don
Sent: Wednesday, November 15, 2006 1:56 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Group B: 22(k) Text-only page


I suppose not; it was a good safety net in the past, and I am thinking
particularly of e-learning applications, which use proprietary engines
with the browser and break the screen reader. This still happens often
and it's nice to be able to insist on an HTML counterpart, although this
is not something which happens all the time. I am on the fence with
this one.

From: Barrett, Don
Date: Wed, Nov 15 2006 1:15 PM
Subject: Re: Group B: 22(k) Text-only page

I suppose not; it was a good safety net in the past, and I am thinking
particularly of e-learning applications, which use proprietary engines
with the browser and break the screen reader. This still happens often
and it's nice to be able to insist on an HTML counterpart, although this
is not something which happens all the time. I am on the fence with
this one.

From: Barrett, Don
Date: Wed, Nov 15 2006 1:20 PM
Subject: Re: Group B: 22(k) Text-only page

I know, it's a goofy standard; specifying text-only as a web requirement
really makes no sense. I have always taken that to mean HTML as a
minimum, but who knows.

From: Hoffman, Allen
Date: Wed, Nov 15 2006 1:25 PM
Subject: Re: Group B: 22(k) Text-only page

I've seen many try text-only pages even now.



Allen Hoffman -- 202-447-0303

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
Fratkin, Mike
Sent: Wednesday, November 15, 2006 2:53 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Group B: 22(k) Text-only page

After the first year of Section 508, I have not seen a single instance
of text only pages used to meet compliance.

Mike


Don - do you feel that if this standard was not around that developers
wouldn't know that if they can't meet the subpart 22 standards that they
need to figure out a different or additional way and to claim functional
equivalence?
AWK

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Barrett, Don
> Sent: Wednesday, November 15, 2006 2:33 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Group B: 22(k) Text-only page
>
> The Blackberry is a perfect example of how commercial nonavailability
> can stop 508 in its tracks. People use inaccessible technology all
> the time in the name of nonavailability; it's awful but it happens.
> At least with the text-only standard, you get something out of it.
>

From: Hoffman, Allen
Date: Wed, Nov 15 2006 1:45 PM
Subject: Re: Group B: 22(k) Text-only page

I know I'm breaking the rule, but lets think a bit more out of this
category box. I think there can be some changes to subpart-A that can
say that commercial nonavailability is not applicable in this situation,
or that if it is, the information and data must be provided via an
alternate means.



Allen Hoffman -- 202-447-0303

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of John M
Slatin
Sent: Wednesday, November 15, 2006 1:57 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Group B: 22(k) Text-only page

Don Barrett wrote:
I think we still need it in those cases where a new technology just
can't be made conformant. If we don't have this, then commercial
nonavailability could kick in and the page might go up as is; at least
with this standard, we require a text-only version, which is not
required by commercial nonavailability.

I don't quite understand this argument. If the new technology can't be
made conformant, it shouldn't be used, or else an alternative version
that does conform should be provided. Text-only is OK for users who are
blind, but it's no help at all to users with dyslexia, for example,
unless the text is also written for a high degree of readability.

It seems to me that vendors interested in having their technologies used
in sites and applications that have to meet 508 should also be
interested in using the appropriate APIs and doing other work necessary
tfor the technologies to conform.



"Good design is accessible design"
John Slatin, Director
Accessibility Institute University of Texas at Austin 1 University
station Stop G9600 Austin, TX 78712, USA Phone +1.512.495.4288 Fax
+1.512.495.4524 cell +1.512.784.7533 email = EMAIL ADDRESS REMOVED =
www.utexas.edu/research/accessibility/

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
Barrett, Don
Sent: Wednesday, November 15, 2006 12:08 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Group B: 22(k) Text-only page


"In reference to CFR1194.22K, Andrew Kirkpatrick wrote:
"It seems odd that the web section has its own functional equivalence
exception. Do we need this?"

I think we still need it in those cases where a new technology just
can't be made conformant. If we don't have this, then commercial
nonavailability could kick in and the page might go up as is; at least
with this standard, we require a text-only version, which is not
required by commercial nonavailability.

From: Travis Roth
Date: Wed, Nov 15 2006 4:00 PM
Subject: Re: Group B: 22(k) Text-only page

John Slatin wrote:
"Text-only is OK for users who are blind"

I find that "text-only" is too restrictive for all in many instances. In the
case of the web, does "text-only" allow for there to be a method of
navigation to move from page to page? Or is an entire set of content or
application supposed to be presented on one browser page? Are forms or any
interactive activity allowed?
And how does one make a "text-only" version of a web application?

A statement that says that as a last case scenario to provide an equivalent
alternative and to do this using proven accessible technologies seems more
useful and helpful.

--
Travis Roth
Production Manager
TecAccess, LLC
(804) 749-8646 (office)
(402) 466-0907 (direct)
= EMAIL ADDRESS REMOVED =
www.TecAccess.net
Experts in Section 508 Compliance & Accessibility

NOTICE: This communication may contain privileged or other confidential
information. If you are not the intended recipient or believe that you may
have
received this communication in error, please reply to the sender indicating
that fact and delete the copy you received. Thank you.

From: Bailey Bruce
Date: Wed, Nov 15 2006 5:30 PM
Subject: Re: Group B: 22(k) Text-only page

John Slatin wrote:
> If the new technology, can't be made conformant, it shouldn't be used,

This is the enigma of quote conformant with the standards unquote versus
actually being accessible. As it stands now, inaccessible E&IT is
permitted in many situations because of legitimate exceptions,
commercial non-availability being one of the more often invoked
rational. This is IMHO one of the more fundamental differences between
508 1194 and WCAG 2.0.

> or else an alternative version that does conform should be provided.

In the Federal space, assuming the commercial non-availability claim to
be valid, 504 ensures that accommodations are still required to be
provided as needed. It is only in the web arena, because of 1194.22(k),
that an alternative version is necessary by design.

> Text-only is OK for users who are blind, but it's no help at
> all to users with dyslexia, for example, unless the text is
> also written for a high degree of readability.

As Don wrote, since .22(k) maps to WCAG 1.0 Checkpoint 11.4, what
exactly qualifies as quote text-only unquote could stand to be
clarified. When I did testing at ED, we were always pleased to allow
the alternative version to be robust, just so long as it satisfies all
the other 1194.22 provisions. Sometimes the alternative versions
offered are too stripped down, they are not functionally equivalent, and
therefore they are not acceptable. If the vendor claims an alternative
version is an equivalent, it is almost always an enlightening exercise
to ask them: Why not scrap the inaccessible version and instead provide
*everyone* the alternative version?

> It seems to me that vendors interested in having their
> technologies used in sites and applications that have to meet
> 508 should also be interested in using the appropriate APIs
> and doing other work necessary for the technologies to conform.

As Don wrote, it is an issue of having a fall-back when technology
conforms by virtue of a legitimate exception rather than conforming by
satisfying all the applicable technical (Subpart B) provisions. Should
this alternative version provision be a requirement for all E&IT? Is
web content different and important enough that only it needs such a
"last resort" clause? Or, as Andrew Kirkpatrick asked, do we need this
at all?

From: Jim Thatcher
Date: Wed, Nov 15 2006 6:40 PM
Subject: Re: Group B: 22(k) Text-only page

Proposal:

22(k) Alternate versions of pages which comply with these provisions with
equivalent information and functionality shall be provided when compliance
cannot be accomplished in any other way. The content of the alterative pages
shall be updated whenever the primary pages change and available with the
same ease as the primary pages.

The reason for this proposal is to remove the phrase "text only" which is
inappropriate, and, in essence, replace it with "compliant."

I fear that "available with the same ease" is not readily testable.

Here, for reference is the current WCAG Success Criterion related to this.

4.2.1 At least one version of the content meets all level 1 success
criteria, but alternate version(s) that do not meet all level 1 success
criteria may be available from the same URI. [How to meet 4.2.1]

Jim

Accessibility Consulting: http://jimthatcher.com/
512-306-0931

From: Jonathan Avila
Date: Wed, Nov 15 2006 8:10 PM
Subject: Re: Group B: 22(k) Text-only page

<blockquote>
22(k) Alternate versions of pages which comply with these provisions with
equivalent information and functionality shall be provided when compliance
cannot be accomplished in any other way. The content of the alterative pages
shall be updated whenever the primary pages change and available with the
same ease as the primary pages.
</blockquote>

I like the proposed 22(k) better than the w3c guideline. As a low vision
user I don't consider a text only page even when total equivalent equal
access. I actually like something that is visually pleasing and accessible
with assistive technology. Thus, I'm glad we are promoting compliant pages
rather than text only pages.

Jonathan

From: Brett, Thomas F
Date: Thu, Nov 16 2006 5:30 AM
Subject: Re: Group B: 22(k) Text-only page

This seems the appropriate place to bring up an issue that I face.

What should happen when a paper document is scanned into a TIFF of PDF
format and then displays the images on a web site? I am not aware of
any screen reader that is capable of reading those images. There is
technology that will extract the OCR from the images and present that
OCR to a person with disabilities, however even with the best scanning
technology we are only talking about 92-96% accuracy. This accuracy is
only for the typed text from the original document and would not include
hand written notes or signatures.

Tom Brett,
Section 508 Coordinator
US Office of Personnel Management
Rm 6H34A
2026061206 (v)
2026062582 (tty)
Disabled does not mean Unable
= EMAIL ADDRESS REMOVED =

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim
Thatcher
Sent: Wednesday, November 15, 2006 8:38 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Group B: 22(k) Text-only page

Proposal:

22(k) Alternate versions of pages which comply with these provisions
with
equivalent information and functionality shall be provided when
compliance
cannot be accomplished in any other way. The content of the alterative
pages
shall be updated whenever the primary pages change and available with
the
same ease as the primary pages.

The reason for this proposal is to remove the phrase "text only" which
is
inappropriate, and, in essence, replace it with "compliant."

I fear that "available with the same ease" is not readily testable.

Here, for reference is the current WCAG Success Criterion related to
this.

4.2.1 At least one version of the content meets all level 1 success
criteria, but alternate version(s) that do not meet all level 1 success
criteria may be available from the same URI. [How to meet 4.2.1]

Jim

Accessibility Consulting: http://jimthatcher.com/
512-306-0931

From: Fratkin, Mike
Date: Thu, Nov 16 2006 5:45 AM
Subject: Re: Group B: 22(k) Text-only page

This is an issue SSA faces every day as we are making "electronic" about
350 million pages a year of medical evidence. We do have a procedure to
use Kurzweil as a virtual print driver that will OCR and speak the TIFF
images. However, the source of the document is the real issue and until
we standardize on making health records electronic, we will continue to
see this issue. There seems to also be a growing tendency to scan other
types of paper documents to PDF or TIFF format and again the source is
the key to being accessible. Beyond the issues of handwritten
information and notes are tables, forms, EKG's, etc. SSA has been
working on this for the past two years and have been able to provide
some capabilities but for the most part technology and other solutions
are not quite there yet.

Mike Fratkin
Social Security Administration (SSA)


[Tom Brett wrote] This seems the appropriate place to bring up an issue
that I face.

What should happen when a paper document is scanned into a TIFF of PDF
format and then displays the images on a web site? I am not aware of
any screen reader that is capable of reading those images. There is
technology that will extract the OCR from the images and present that
OCR to a person with disabilities, however even with the best scanning
technology we are only talking about 92-96% accuracy. This accuracy is
only for the typed text from the original document and would not include
hand written notes or signatures.

Tom Brett,
Section 508 Coordinator
US Office of Personnel Management
Rm 6H34A
2026061206 (v)
2026062582 (tty)
Disabled does not mean Unable
= EMAIL ADDRESS REMOVED =

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim
Thatcher
Sent: Wednesday, November 15, 2006 8:38 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Group B: 22(k) Text-only page

Proposal:

22(k) Alternate versions of pages which comply with these provisions
with equivalent information and functionality shall be provided when
compliance cannot be accomplished in any other way. The content of the
alterative pages shall be updated whenever the primary pages change and
available with the same ease as the primary pages.

The reason for this proposal is to remove the phrase "text only" which
is inappropriate, and, in essence, replace it with "compliant."

I fear that "available with the same ease" is not readily testable.

Here, for reference is the current WCAG Success Criterion related to
this.

4.2.1 At least one version of the content meets all level 1 success
criteria, but alternate version(s) that do not meet all level 1 success
criteria may be available from the same URI. [How to meet 4.2.1]

Jim

Accessibility Consulting: http://jimthatcher.com/
512-306-0931

From: Barrett, Don
Date: Thu, Nov 16 2006 5:50 AM
Subject: Re: Group B: 22(k) Text-only page

Wonderful!

From: Brett, Thomas F
Date: Thu, Nov 16 2006 6:35 AM
Subject: Re: Group B: 22(k) Text-only page

If an alternative device is being used to read the OCR and speak the
TIFF images, it would seem to me that this would not be comparable
access. This would be an accommodation for people with disabilities.
Shouldn't the image be directly accessible via the screen reader?

Tom Brett,
Section 508 Coordinator
US Office of Personnel Management
Rm 6H34A
2026061206 (v)
2026062582 (tty)
Disabled does not mean Unable
= EMAIL ADDRESS REMOVED =

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
Fratkin, Mike
Sent: Thursday, November 16, 2006 7:44 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Group B: 22(k) Text-only page

This is an issue SSA faces every day as we are making "electronic" about
350 million pages a year of medical evidence. We do have a procedure to
use Kurzweil as a virtual print driver that will OCR and speak the TIFF
images. However, the source of the document is the real issue and until
we standardize on making health records electronic, we will continue to
see this issue. There seems to also be a growing tendency to scan other
types of paper documents to PDF or TIFF format and again the source is
the key to being accessible. Beyond the issues of handwritten
information and notes are tables, forms, EKG's, etc. SSA has been
working on this for the past two years and have been able to provide
some capabilities but for the most part technology and other solutions
are not quite there yet.

Mike Fratkin
Social Security Administration (SSA)


[Tom Brett wrote] This seems the appropriate place to bring up an issue
that I face.

What should happen when a paper document is scanned into a TIFF of PDF
format and then displays the images on a web site? I am not aware of
any screen reader that is capable of reading those images. There is
technology that will extract the OCR from the images and present that
OCR to a person with disabilities, however even with the best scanning
technology we are only talking about 92-96% accuracy. This accuracy is
only for the typed text from the original document and would not include
hand written notes or signatures.

Tom Brett,
Section 508 Coordinator
US Office of Personnel Management
Rm 6H34A
2026061206 (v)
2026062582 (tty)
Disabled does not mean Unable
= EMAIL ADDRESS REMOVED =

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim
Thatcher
Sent: Wednesday, November 15, 2006 8:38 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Group B: 22(k) Text-only page

Proposal:

22(k) Alternate versions of pages which comply with these provisions
with equivalent information and functionality shall be provided when
compliance cannot be accomplished in any other way. The content of the
alterative pages shall be updated whenever the primary pages change and
available with the same ease as the primary pages.

The reason for this proposal is to remove the phrase "text only" which
is inappropriate, and, in essence, replace it with "compliant."

I fear that "available with the same ease" is not readily testable.

Here, for reference is the current WCAG Success Criterion related to
this.

4.2.1 At least one version of the content meets all level 1 success
criteria, but alternate version(s) that do not meet all level 1 success
criteria may be available from the same URI. [How to meet 4.2.1]

Jim

Accessibility Consulting: http://jimthatcher.com/
512-306-0931

From: Bailey Bruce
Date: Thu, Nov 16 2006 6:40 AM
Subject: Re: Group B: 22(k) Text-only page

Just being picayune here...

Jonathan writes:
> I like the proposed 22(k) better than the w3c guideline. As
> a low vision user I don't consider a text only page even when
> total equivalent equal access.

I think you mean WCAG Checkpoint (not W3C guideline) but WCAG doesn't
use the term text only page. That misnomer was introduced by the 508
rephrasing of Checkpoint 11.4. Follows are the versions in
chronological order.

WCAG 1.0 11.4: If, after best efforts, you cannot create an accessible
page, provide a link to an alternative page that uses W3C technologies,
is accessible, has equivalent information (or functionality), and is
updated as often as the inaccessible (original) page.

1194.22(k): A text-only page, with equivalent information or
functionality, shall be provided to make a web site comply with the
provisions of this part, when compliance cannot be accomplished in any
other way. The content of the text-only page shall be updated whenever
the primary page changes.

WCAG 2.0 (working draft) 4.2.1: At least one version of the content
meets all level 1 success criteria, but alternate version(s) that do not
meet all level 1 success criteria may be available from the same URI.

WCAG 2.0 (editor's draft) 4.2.1: When multiple versions of the same
content are available, at least one version meets all level 1 success
criteria. Any version that does not meet all level 1 success criteria
provides a mechanism to obtain a version that does, and that mechanism
meets all level 1 success criteria.

Jim Thatcher's proposed rewrite of 22(k): Alternate versions of pages
which comply with these provisions with equivalent information and
functionality shall be provided when compliance cannot be accomplished
in any other way. The content of the alterative pages shall be updated
whenever the primary pages change and available with the same ease as
the primary pages.

From: Sean Hayes
Date: Thu, Nov 16 2006 6:45 AM
Subject: Re: Group B: 22(k) Text-only page

Can somebody provide an example of how this would work in practice?

Not wishing to be contrarian; but if it is not possible to make a page comply, then I'm failing to see how it is possible to create a fully equivalent alternate that does comply; if this were possible, then surely the same technique could be used in the main page - what am I missing here?

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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Bailey Bruce
Sent: 16 November 2006 13:36
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Group B: 22(k) Text-only page

Just being picayune here...

Jonathan writes:
> I like the proposed 22(k) better than the w3c guideline. As
> a low vision user I don't consider a text only page even when
> total equivalent equal access.

I think you mean WCAG Checkpoint (not W3C guideline) but WCAG doesn't
use the term text only page. That misnomer was introduced by the 508
rephrasing of Checkpoint 11.4. Follows are the versions in
chronological order.

WCAG 1.0 11.4: If, after best efforts, you cannot create an accessible
page, provide a link to an alternative page that uses W3C technologies,
is accessible, has equivalent information (or functionality), and is
updated as often as the inaccessible (original) page.

1194.22(k): A text-only page, with equivalent information or
functionality, shall be provided to make a web site comply with the
provisions of this part, when compliance cannot be accomplished in any
other way. The content of the text-only page shall be updated whenever
the primary page changes.

WCAG 2.0 (working draft) 4.2.1: At least one version of the content
meets all level 1 success criteria, but alternate version(s) that do not
meet all level 1 success criteria may be available from the same URI.

WCAG 2.0 (editor's draft) 4.2.1: When multiple versions of the same
content are available, at least one version meets all level 1 success
criteria. Any version that does not meet all level 1 success criteria
provides a mechanism to obtain a version that does, and that mechanism
meets all level 1 success criteria.

Jim Thatcher's proposed rewrite of 22(k): Alternate versions of pages
which comply with these provisions with equivalent information and
functionality shall be provided when compliance cannot be accomplished
in any other way. The content of the alterative pages shall be updated
whenever the primary pages change and available with the same ease as
the primary pages.

From: Fratkin, Mike
Date: Thu, Nov 16 2006 6:55 AM
Subject: Re: Group B: 22(k) Text-only page

It is not really a device but another piece of assistive software.
Sure, it would be nice if screen readers could read images, but they can
speak the results of the OCR process. This would require extra steps.
The bottom line, however, is that a FAX or a scanned image is only as
accessible as the source document. SSA looked at 20 different document
types and after they were OCR'd the error rates were as follows:

Typed 6.5%
Typed with notes 6.1%
Faxes 14.4%
Pictures and graphs 23.4%
Handwritten 36.2%
EKG 49.7%

So, depending on the nature of the job, the accuracy is very important.
The documents that we are working with currently from doctors,
hospitals, clinics, etc. is in every format possible, so at the present
time will be very difficult to be usable.

Mike Fratkin

[Tom Brett wrote] If an alternative device is being used to read the OCR
and speak the TIFF images, it would seem to me that this would not be
comparable access. This would be an accommodation for people with
disabilities.
Shouldn't the image be directly accessible via the screen reader?

Tom Brett,
Section 508 Coordinator
US Office of Personnel Management
Rm 6H34A
2026061206 (v)
2026062582 (tty)
Disabled does not mean Unable
= EMAIL ADDRESS REMOVED =

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
Fratkin, Mike
Sent: Thursday, November 16, 2006 7:44 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Group B: 22(k) Text-only page

This is an issue SSA faces every day as we are making "electronic" about
350 million pages a year of medical evidence. We do have a procedure to
use Kurzweil as a virtual print driver that will OCR and speak the TIFF
images. However, the source of the document is the real issue and until
we standardize on making health records electronic, we will continue to
see this issue. There seems to also be a growing tendency to scan other
types of paper documents to PDF or TIFF format and again the source is
the key to being accessible. Beyond the issues of handwritten
information and notes are tables, forms, EKG's, etc. SSA has been
working on this for the past two years and have been able to provide
some capabilities but for the most part technology and other solutions
are not quite there yet.

Mike Fratkin
Social Security Administration (SSA)


[Tom Brett wrote] This seems the appropriate place to bring up an issue
that I face.

What should happen when a paper document is scanned into a TIFF of PDF
format and then displays the images on a web site? I am not aware of
any screen reader that is capable of reading those images. There is
technology that will extract the OCR from the images and present that
OCR to a person with disabilities, however even with the best scanning
technology we are only talking about 92-96% accuracy. This accuracy is
only for the typed text from the original document and would not include
hand written notes or signatures.

Tom Brett,
Section 508 Coordinator
US Office of Personnel Management
Rm 6H34A
2026061206 (v)
2026062582 (tty)
Disabled does not mean Unable
= EMAIL ADDRESS REMOVED =

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim
Thatcher
Sent: Wednesday, November 15, 2006 8:38 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Group B: 22(k) Text-only page

Proposal:

22(k) Alternate versions of pages which comply with these provisions
with equivalent information and functionality shall be provided when
compliance cannot be accomplished in any other way. The content of the
alterative pages shall be updated whenever the primary pages change and
available with the same ease as the primary pages.

The reason for this proposal is to remove the phrase "text only" which
is inappropriate, and, in essence, replace it with "compliant."

I fear that "available with the same ease" is not readily testable.

Here, for reference is the current WCAG Success Criterion related to
this.

4.2.1 At least one version of the content meets all level 1 success
criteria, but alternate version(s) that do not meet all level 1 success
criteria may be available from the same URI. [How to meet 4.2.1]

Jim

Accessibility Consulting: http://jimthatcher.com/
512-306-0931

From: Gregg Vanderheiden
Date: Thu, Nov 16 2006 9:30 AM
Subject: Re: Group B: 22(k) Text-only page

They may be using a technology on the main page that does not support
access. For example the page may be an immersive environment.


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



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Sean Hayes
> Sent: Thursday, November 16, 2006 7:44 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Group B: 22(k) Text-only page
>
> Can somebody provide an example of how this would work in practice?
>
> Not wishing to be contrarian; but if it is not possible to
> make a page comply, then I'm failing to see how it is
> possible to create a fully equivalent alternate that does
> comply; if this were possible, then surely the same technique
> could be used in the main page - what am I missing here?
>
> Sean Hayes
> Standards and Policy Team
> Accessible Technology Group
> Microsoft
> Phone:
> mob +44 7977 455002
> office +44 117 9719730
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Bailey Bruce
> Sent: 16 November 2006 13:36
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] Group B: 22(k) Text-only page
>
> Just being picayune here...
>
> Jonathan writes:
> > I like the proposed 22(k) better than the w3c guideline. As a low
> > vision user I don't consider a text only page even when total
> > equivalent equal access.
>
> I think you mean WCAG Checkpoint (not W3C guideline) but WCAG
> doesn't use the term text only page. That misnomer was
> introduced by the 508 rephrasing of Checkpoint 11.4. Follows
> are the versions in chronological order.
>
> WCAG 1.0 11.4: If, after best efforts, you cannot create an
> accessible page, provide a link to an alternative page that
> uses W3C technologies, is accessible, has equivalent
> information (or functionality), and is updated as often as
> the inaccessible (original) page.
>
> 1194.22(k): A text-only page, with equivalent information or
> functionality, shall be provided to make a web site comply
> with the provisions of this part, when compliance cannot be
> accomplished in any other way. The content of the text-only
> page shall be updated whenever the primary page changes.
>
> WCAG 2.0 (working draft) 4.2.1: At least one version of the content
> meets all level 1 success criteria, but alternate version(s)
> that do not meet all level 1 success criteria may be
> available from the same URI.
>
> WCAG 2.0 (editor's draft) 4.2.1: When multiple versions of
> the same content are available, at least one version meets
> all level 1 success criteria. Any version that does not meet
> all level 1 success criteria provides a mechanism to obtain a
> version that does, and that mechanism meets all level 1
> success criteria.
>
> Jim Thatcher's proposed rewrite of 22(k): Alternate versions
> of pages which comply with these provisions with equivalent
> information and functionality shall be provided when
> compliance cannot be accomplished in any other way. The
> content of the alterative pages shall be updated whenever the
> primary pages change and available with the same ease as the
> primary pages.
>
>