Thread Subject: Re: Final? draft of 1194.41a, b,and c (was discussion of who pays for alternate format)

Return to this mailing list's archives

From: Robinson, Norman B - Washington, DC
Date: Mon, Mar 19 2007 12:45 PM
Subject: Re: Final? draft of 1194.41a, b,and c (was discussion of who pays for alternate format)

An observation: what is the definition of alternate formats or alternate methods?

1. What would be examples of how this should be implemented?
e.g.: We provide documentation in PDF format that (we believe) meets all the 1194 subpart B and C requirements. What happens with the users that can't open a PDF v 12 using their assistive technology or it doesn't work on their platform/operating system? That is, what happens when the end-user deems the format unacceptable? If I don't run MS Office at home, is a MS Word document acceptable? What is the acceptable alternate format for blueprints? We've have a primitive approach to this in our USPS policy: http://www.usps.com/cpim/ftp/hand/as508a/508a_c6.html#508hdr79.

2. Are we addressing the real world need for accessible electronic formats (and not just Braille or other options)?

3. What would be examples of how this could be implemented in undesirable ways?
e.g., We provide documentation in one format only, which our legal council has deemed meets our legal requirements since [vendor specific example] is commonly available. Assume there is no accessible plug-in for [vendor specific format]. Assume the vendor software costs a significant amount of money to obtain. Generally, I've found this is left until someone actually makes a request, then the responsible program has to back-track into satisfying the end-user's needs.

Who _legally_ determines what is an acceptable alternate format? Do we expect when reasonable people disagree, the desired course of action would be for the affected individual to file a Section 508 complaint? Do we expect clarification in the next version of the Section 508 technical standards that describes what the best practice or acceptable formats should be allowed?

Regards,


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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Michele Budris
Sent: Friday, March 16, 2007 4:15 PM
To: TEITAC documentation and technical support subcommittee
Subject: [teitac-documentation] Final? draft of 1194.41a, b, and c (was discussion of who pays for alternate format)


In the discussions of how to make clear who pays for alternate formats the proposal was made to rewrite 1194.41a, b, and c to be the text below. In the March 15, 2007 meeting it was agreed to make this the final version unless issues are raised. Deadline for feedback is Friday, March 26, 2007.



Subpart D -- Information, Documentation, and Support

§ 1194.41 Information, documentation, and support.

(a) To enable Federal agencies to provide product support documentation to end-users in an accessible format, Federal agencies shall require that all documentation supporting the product, including but not limited to reports, system documentation and end user training or technical support materials shall conform the relevant accessibility provisions in 1194 Subparts B and C.

(b) Federal agencies shall provide end-users access to a description of the accessibility and compatibility features of products in alternate formats or alternate methods upon request.

(c) Support services for products shall accommodate the communication needs of end-users with disabilities

Best Practice : If the documentation supporting the product, reports or other documentation are to be provided via a contract, then the contract must include this requirement.

If the descriptions for the end-users regarding the accessibility and compatibility features of products in alternate formats are to be provided via a contract, then the contract must include this requirement.



Michele

From: Debbie Cook
Date: Mon, Mar 19 2007 12:55 PM
Subject: Re: Final? draft of 1194.41a, b,and c (was discussion of who pays for alternate format)

I have always preferred to require an accessible electronic format which can
be converted to other alternative formats on demand as an accommodation.
That electronic format is dictated by the audience. If it's federal
employees, it's reasonable to assume that they have provided applications
for reading it. If it's the public, then there are fewer options. Doesn't
preclude someone from still requesting an accommodation of the material in a
particular format because they cannot use the accessible one. If I create an
accessible PDF but lots of users can't use it because they don't have enough
PC power to run theaccess tools etc. then I'll get more requests for
alternative formats and I might want to reconsider in the future.
----- Original Message -----
From: "Robinson, Norman B - Washington, DC" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC documentation and technical support subcommittee"
< = EMAIL ADDRESS REMOVED = >
Sent: Monday, March 19, 2007 12:41 PM
Subject: Re: [teitac-documentation] Final? draft of 1194.41a, b,and c (was
discussion of who pays for alternate format)



An observation: what is the definition of alternate formats or alternate
methods?

1. What would be examples of how this should be implemented?
e.g.: We provide documentation in PDF format that (we believe)
meets all the 1194 subpart B and C requirements. What happens with the users
that can't open a PDF v 12 using their assistive technology or it doesn't
work on their platform/operating system? That is, what happens when the
end-user deems the format unacceptable? If I don't run MS Office at home, is
a MS Word document acceptable? What is the acceptable alternate format for
blueprints? We've have a primitive approach to this in our USPS policy:
http://www.usps.com/cpim/ftp/hand/as508a/508a_c6.html#508hdr79.

2. Are we addressing the real world need for accessible electronic
formats (and not just Braille or other options)?

3. What would be examples of how this could be implemented in
undesirable ways?
e.g., We provide documentation in one format only, which our
legal council has deemed meets our legal requirements since [vendor specific
example] is commonly available. Assume there is no accessible plug-in for
[vendor specific format]. Assume the vendor software costs a significant
amount of money to obtain. Generally, I've found this is left until someone
actually makes a request, then the responsible program has to back-track
into satisfying the end-user's needs.

Who _legally_ determines what is an acceptable alternate format? Do
we expect when reasonable people disagree, the desired course of action
would be for the affected individual to file a Section 508 complaint? Do we
expect clarification in the next version of the Section 508 technical
standards that describes what the best practice or acceptable formats should
be allowed?

Regards,


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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Michele
Budris
Sent: Friday, March 16, 2007 4:15 PM
To: TEITAC documentation and technical support subcommittee
Subject: [teitac-documentation] Final? draft of 1194.41a, b, and c (was
discussion of who pays for alternate format)


In the discussions of how to make clear who pays for alternate formats the
proposal was made to rewrite 1194.41a, b, and c to be the text below. In the
March 15, 2007 meeting it was agreed to make this the final version unless
issues are raised. Deadline for feedback is Friday, March 26, 2007.



Subpart D -- Information, Documentation, and Support

§ 1194.41 Information, documentation, and support.

(a) To enable Federal agencies to provide product support documentation to
end-users in an accessible format, Federal agencies shall require that all
documentation supporting the product, including but not limited to reports,
system documentation and end user training or technical support materials
shall conform the relevant accessibility provisions in 1194 Subparts B and
C.

(b) Federal agencies shall provide end-users access to a description of the
accessibility and compatibility features of products in alternate formats or
alternate methods upon request.

(c) Support services for products shall accommodate the communication needs
of end-users with disabilities

Best Practice : If the documentation supporting the product, reports or
other documentation are to be provided via a contract, then the contract
must include this requirement.

If the descriptions for the end-users regarding the accessibility and
compatibility features of products in alternate formats are to be provided
via a contract, then the contract must include this requirement.



Michele





--------------------------------------------------------------------------------

From: David Poehlman
Date: Mon, Mar 19 2007 1:55 PM
Subject: Re: Final? draft of 1194.41a, b,and c (was discussion of who pays for alternate format)

Hi Norman and all,

I'd like to offer a different aapproach. What we need are guidance/
standards if you will that provide a roadmap for formats to be
compliiant. We need to also target the requestor by functionality.
If braille meets the need, it should be braillee and not only
braille, but grade1 if that is what is needed. If casset, asci,,
other commonly used and or open formats meet the need, that should be
supplied. In other words, do away with alternate formats altogether
and talk about compliant formats if you will.

On Mar 19, 2007, at 3:41 PM, Robinson, Norman B - Washington, DC wrote:


An observation: what is the definition of alternate formats or
alternate methods?

1. What would be examples of how this should be implemented?
e.g.: We provide documentation in PDF format that (we
believe) meets all the 1194 subpart B and C requirements. What
happens with the users that can't open a PDF v 12 using their
assistive technology or it doesn't work on their platform/operating
system? That is, what happens when the end-user deems the format
unacceptable? If I don't run MS Office at home, is a MS Word document
acceptable? What is the acceptable alternate format for blueprints?
We've have a primitive approach to this in our USPS policy: http://
www.usps.com/cpim/ftp/hand/as508a/508a_c6.html#508hdr79.

2. Are we addressing the real world need for accessible
electronic formats (and not just Braille or other options)?

3. What would be examples of how this could be implemented
in undesirable ways?
e.g., We provide documentation in one format only, which
our legal council has deemed meets our legal requirements since
[vendor specific example] is commonly available. Assume there is no
accessible plug-in for [vendor specific format]. Assume the vendor
software costs a significant amount of money to obtain. Generally,
I've found this is left until someone actually makes a request, then
the responsible program has to back-track into satisfying the end-
user's needs.

Who _legally_ determines what is an acceptable alternate
format? Do we expect when reasonable people disagree, the desired
course of action would be for the affected individual to file a
Section 508 complaint? Do we expect clarification in the next version
of the Section 508 technical standards that describes what the best
practice or acceptable formats should be allowed?

Regards,


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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto:teitac-
= EMAIL ADDRESS REMOVED = ] On Behalf Of Michele Budris
Sent: Friday, March 16, 2007 4:15 PM
To: TEITAC documentation and technical support subcommittee
Subject: [teitac-documentation] Final? draft of 1194.41a, b, and c
(was discussion of who pays for alternate format)


In the discussions of how to make clear who pays for alternate
formats the proposal was made to rewrite 1194.41a, b, and c to be the
text below. In the March 15, 2007 meeting it was agreed to make this
the final version unless issues are raised. Deadline for feedback is
Friday, March 26, 2007.



Subpart D -- Information, Documentation, and Support

§ 1194.41 Information, documentation, and support.

(a) To enable Federal agencies to provide product support
documentation to end-users in an accessible format, Federal agencies
shall require that all documentation supporting the product,
including but not limited to reports, system documentation and end
user training or technical support materials shall conform the
relevant accessibility provisions in 1194 Subparts B and C.

(b) Federal agencies shall provide end-users access to a description
of the accessibility and compatibility features of products in
alternate formats or alternate methods upon request.

(c) Support services for products shall accommodate the
communication needs of end-users with disabilities

Best Practice : If the documentation supporting the product, reports
or other documentation are to be provided via a contract, then the
contract must include this requirement.

If the descriptions for the end-users regarding the accessibility
and compatibility features of products in alternate formats are to be
provided via a contract, then the contract must include this
requirement.



Michele

From: David Poehlman
Date: Mon, Mar 19 2007 3:30 PM
Subject: Re: Final? draft of 1194.41a, b,and c (was discussion of who pays for alternate format)

Good points.

See my observations in line marked with dp:
On Mar 19, 2007, at 5:36 PM, Whitney Quesenbery wrote:

At 04:52 PM 3/19/2007, David Poehlman wrote:
> In other words, do away with alternate formats altogether
> and talk about compliant formats if you will.

So, if I posted a "file" in several formats and at least one of the
formats
met each of the general functional performance requirements, I'd be in
compliance?
dp: I'd say that all formats used must meet the standards set for
documentation/content. Of course, print on paper would be at least
partially exempt but it should be easily scannable.

As I think about this, I do this all the time, even outside of
disabilities
considerations. For example, if the information if the info is from an
application used by some (but not all) members of a project, I might
send
it out in the native format, but also send an exported format such as
text
or PDF or HTML. (Example: Microsoft Project, which will create a
number of
formats to read a project plan.)
dp: this is an excellent example and one which points out my intent
quite well. Part of the specificationf forr standards would allow
for a project plan too be distributed in formats which at some
functional level met a variety of acccess needs. For instance, the
"normal" way to put this out might be a chart which would be much
more effective for some than streight text and this goes with cognition.

The next question is what is a "sufficient" format. Is it enough to have
formats that (taken as a group) conform to requirements? What else
must be
taken into consideration:
dp: I don't see how a group of formats could be taken to meet the
requirements but I supposse that the rrequirements could be written
and or enterpretted in that way. I'd actually like to see
requirements such that we get cross modality in open standards in any
compliant format but failing that, we could have a provision or set
of provisions which allow forr mmultiiple formats to meet the
requirements as a whole. The problem I see fwith this is that some
mixed modalities might require several formats twhich might defeat
the purposees of dealing with thee issue of mmultiple modalities.
For instance, iff one of the requirements was that the content would
be available in a form which was usable by someonw not using a screen
or their eyes in any other fashion, a typical response would be
audioo. Another might be that the needs of those not listening would
be able to utillize the content so print or visual content would be
appropriate. What though if I don't listen or watch? So we needd an
approach that takes thesee potentially oppositess into account.


-- The capabilities of the users' IT be taken into consideration? The
example above is one (from general use) in which the availability of the
"reader program" is a consideration.
dp: this is why I advocate for open standards here. We cannot
provide with certainty that our format specifications will fit all
situations, but we can at least mittigate this by providing ways to
make it easier to do so.

-- User preferences? I can see how this might be determined through
user
research in a specific case (easier or perhaps more targeted for
employees
than for the public), but how would it be specified as a general
requirement.

-- Availability (% adoption? cost? ease of acquisition/installation?)
of
the AT or "reader program"?

What if I choose not to install a wildly popular and free plugin (e.g.
Acrobat, Flash)? Is that "my choice" but not "your responsibility"?
dp: if the format is open and there is something freely available
that will not trump the user environment, it becomes the
responsibility of the user.

Whitney Quesenbery
Whitney Interactive Design
= EMAIL ADDRESS REMOVED =
phone: 908-638-5467
mobile: 908-328-5959
www.WQusability.com
www.usabilityprofessionals.org

"Warning: Objects in the calendar are closer than they appear."

From: David Poehlman
Date: Mon, Mar 19 2007 4:00 PM
Subject: Re: Final? draft of 1194.41a, b,and c (was discussion of who pays for alternate format)

Hi,

This example fits with my thinking. It iss not a format exactly, it
is a conceptual format.. The actuall concept I think is a diagramm
with complete narative. In this way, the diagram can be detatched or
made tactile etc. The fconcepts would be audio, visual, electronic
textual and tactile aand probably others and an appropriate mixture
for meetinggg multiiple functional needs. So, the bigggest issues we
have here are what electronic forms something should take in order to
satisfy our requirements that the content be acccessible. Tactile
and audio are almost easy although we could set standards for them as
well relying on information ffrom the Library of congress (NLS),,
AAmerican foundation for the blind and others. Whether it is mixed
content or pure graphical or textual, it needs too bee in formats
which meet requirements yet to be deterrmined. In my estimate, what
would be a logical approach would be that if it is streight text,
there needs to be something diamagratic or visually apppropriate to
rrepresent it for those who need that and vise verssa. If it is
purely graphical, it needs to also be textual. This can become
complex and it can also bboil down to an easy way to meet needs..

IiIn other words, mixed content must meet functional requirements.
and that is where the formats come into play for dealing with the
objects in the content. Pleae remember, we haven't written these
requirements as yet but if it is possible to do so, I believe a lot
of ambiguity can be dealt with.

Thanks!

On Mar 19, 2007, at 6:37 PM, Whitney Quesenbery wrote:

At 06:26 PM 3/19/2007, David Poehlman wrote:
> dp: I don't see how a group of formats could be taken to meet the
> requirements but I supposse that the requirements could be written
> and or enterpreted in that way. I'd actually like to see
> requirements such that we get cross modality in open standards in any
> compliant format but failing that, we could have a provision or set
> of provisions which allow for multiiple formats to meet the
> requirements as a whole.

WQ: Good point, in applications/formats where this is possible. What
about:
a diagram in a graphics format and an accompanying textual description.



Whitney Quesenbery
Whitney Interactive Design
= EMAIL ADDRESS REMOVED =
phone: 908-638-5467
mobile: 908-328-5959
www.WQusability.com
www.usabilityprofessionals.org

"Warning: Objects in the calendar are closer than they appear."

From: Gregg Vanderheiden
Date: Mon, Mar 19 2007 7:45 PM
Subject: Re: Final? draft of 1194.41a, b,and c (was discussion of who pays for alternate format)

In WCAG we also talk about the accessible format being findable from the
inaccessible one. Often you just get a link to one format. If it isn't
accessible there needs to be some mechanism to find one that is or it
doesn't help you much.


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



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Whitney Quesenbery
> Sent: Monday, March 19, 2007 4:36 PM
> To: TEITAC documentation and technical support subcommittee
> Subject: Re: [teitac-documentation] Final? draft of 1194.41a,
> b, and c (was discussion of who pays for alternate format)
>
> At 04:52 PM 3/19/2007, David Poehlman wrote:
> >In other words, do away with alternate formats altogether and talk
> >about compliant formats if you will.
>
> So, if I posted a "file" in several formats and at least one
> of the formats met each of the general functional performance
> requirements, I'd be in compliance?
>
> As I think about this, I do this all the time, even outside
> of disabilities considerations. For example, if the
> information if the info is from an application used by some
> (but not all) members of a project, I might send it out in
> the native format, but also send an exported format such as
> text or PDF or HTML. (Example: Microsoft Project, which will
> create a number of formats to read a project plan.)
>
> The next question is what is a "sufficient" format. Is it
> enough to have formats that (taken as a group) conform to
> requirements? What else must be taken into consideration:
>
> -- The capabilities of the users' IT be taken into
> consideration? The example above is one (from general use) in
> which the availability of the "reader program" is a consideration.
>
> -- User preferences? I can see how this might be determined
> through user research in a specific case (easier or perhaps
> more targeted for employees than for the public), but how
> would it be specified as a general requirement.
>
> -- Availability (% adoption? cost? ease of
> acquisition/installation?) of the AT or "reader program"?
>
> What if I choose not to install a wildly popular and free
> plugin (e.g.
> Acrobat, Flash)? Is that "my choice" but not "your responsibility"?
>
>
>
>
> Whitney Quesenbery
> Whitney Interactive Design
> = EMAIL ADDRESS REMOVED =
> phone: 908-638-5467
> mobile: 908-328-5959
> www.WQusability.com
> www.usabilityprofessionals.org
>
> "Warning: Objects in the calendar are closer than they appear."
>
>

From: Baker, Robert C.
Date: Tue, Mar 20 2007 6:45 AM
Subject: Re: Final? draft of 1194.41a, b,and c (was discussion of who pays for alternate format)

Greg raises a good point. Accessible formats of non-accessible content
should be readily accessible within close proximity of the original
content when published on a web page.

From: Lybarger, Barbara (MOD)
Date: Tue, Mar 20 2007 11:00 AM
Subject: Re: Final? draft of 1194.41a, b,and c (was discussion of who pays for alternate format)

In the best practice statements it is very good to state that the contract repeats the specific regulation language. I would add that "This makes clear to those bidding on the contract that they need to address those issues."

Barbara

From: Gregg Vanderheiden
Date: Tue, Mar 20 2007 1:20 PM
Subject: Re: Final? draft of 1194.41a, b,and c (was discussion of who pays for alternate format)

In WCAG we have talked about a mechanism available from the inaccessible
version. The concern being that often the URI of the inaccessible doc is
sent in an email etc and that there isn't a way to get to the accessible
version from the inaccessible version if you don't know the unknown page
that references both.

Some interesting techniques for this too.


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



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Baker, Robert C.
> Sent: Tuesday, March 20, 2007 8:39 AM
> To: TEITAC documentation and technical support subcommittee
> Subject: Re: [teitac-documentation] Final? draft of 1194.41a,
> b,and c (was discussion of who pays for alternate format)
>
> Greg raises a good point. Accessible formats of
> non-accessible content
> should be readily accessible within close proximity of the
> original content when published on a web page.
>
>
>