Thread Subject: Re: intro for 8.1?

Return to this mailing list's archives

From: Hoffman, Allen
Date: Thu, Sep 20 2007 9:50 AM
Subject: Re: intro for 8.1?

All:

Several people have raised questions related to how provisions in 8.1
relate to other sections. I think I'd like to propose an update to the
draft for 09/14 to include some intro materials to alleviate this
concern, as it is obvious some connection is needed to make this
self-evident.

So:

Sections 3 and 6 above require that information delivered must be
presented meeting accessibility requirements. To accomplish this,
information storage formats must allow for inclusion of certain
accessibility related attributes and/or functionalities. This section
describes the functional accessibility requirements for such formats.
When determining the most accessible product from a set of more than
one, the format information is provided in can determine if other
requirements can be met or not, and can be an important factor in the
final determination. Note: Formats which do not include some
functionalities such as the ability to represent synchronized media,
would not be subject to that provision.

From: Jim Tobias
Date: Thu, Sep 20 2007 10:35 AM
Subject: Re: intro for 8.1?

Thanks, Allen -- this is an important and necessary addition. We should
probably draft similar introductions for other sections, wherver there may
be doubt as to how to apply provisions.

***
Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias


> -----Original Message-----
> From: Hoffman, Allen [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Thursday, September 20, 2007 11:43 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> All:
>
> Several people have raised questions related to how
> provisions in 8.1 relate to other sections. I think I'd like
> to propose an update to the draft for 09/14 to include some
> intro materials to alleviate this concern, as it is obvious
> some connection is needed to make this self-evident.
>
> So:
>
> Sections 3 and 6 above require that information delivered
> must be presented meeting accessibility requirements. To
> accomplish this, information storage formats must allow for
> inclusion of certain accessibility related attributes and/or
> functionalities. This section describes the functional
> accessibility requirements for such formats.
> When determining the most accessible product from a set of
> more than one, the format information is provided in can
> determine if other requirements can be met or not, and can be
> an important factor in the final determination. Note:
> Formats which do not include some functionalities such as the
> ability to represent synchronized media, would not be subject
> to that provision.
>
>
>

From: Andrew Kirkpatrick
Date: Thu, Sep 20 2007 11:05 AM
Subject: Re: intro for 8.1?

Allen,

You state "When determining the most accessible product from a set of
more than one, the format information is provided in can determine if
other requirements can be met or not" but just because a format includes
support for a particular standard it doesn't mean that the product that
uses that format takes advantage of that support.

How do you envision the support for the content formats being defined?
Does each content format have a VPAT? If so, who writes it?

Part of my concern with the implementation of this section is that the
product is already reporting on how they support standards that overlap
with the content format items - I'm not sure that it will actually help
in procurement decisions since the product needs to meet the section 3
standards, and the section 8 standards not only don't bring anything new
to the picture but they are not necessarily representative of the
accessibility in the specific product.

AWK





> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Hoffman, Allen
> Sent: Thursday, September 20, 2007 11:43 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> All:
>
> Several people have raised questions related to how
> provisions in 8.1 relate to other sections. I think I'd like
> to propose an update to the draft for 09/14 to include some
> intro materials to alleviate this concern, as it is obvious
> some connection is needed to make this self-evident.
>
> So:
>
> Sections 3 and 6 above require that information delivered
> must be presented meeting accessibility requirements. To
> accomplish this, information storage formats must allow for
> inclusion of certain accessibility related attributes and/or
> functionalities. This section describes the functional
> accessibility requirements for such formats.
> When determining the most accessible product from a set of
> more than one, the format information is provided in can
> determine if other requirements can be met or not, and can be
> an important factor in the final determination. Note:
> Formats which do not include some functionalities such as the
> ability to represent synchronized media, would not be subject
> to that provision.
>
>
>

From: Hoffman, Allen
Date: Thu, Sep 20 2007 11:15 AM
Subject: Re: intro for 8.1?

Look at it as a sanity check.
If you state that, for example, you meet the language requirement in 3,
but select a format that doesn't include that capacity, something is
wrong.



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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andrew
Kirkpatrick
Sent: Thursday, September 20, 2007 1:04 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] intro for 8.1?

Allen,

You state "When determining the most accessible product from a set of
more than one, the format information is provided in can determine if
other requirements can be met or not" but just because a format includes
support for a particular standard it doesn't mean that the product that
uses that format takes advantage of that support.

How do you envision the support for the content formats being defined?
Does each content format have a VPAT? If so, who writes it?

Part of my concern with the implementation of this section is that the
product is already reporting on how they support standards that overlap
with the content format items - I'm not sure that it will actually help
in procurement decisions since the product needs to meet the section 3
standards, and the section 8 standards not only don't bring anything new
to the picture but they are not necessarily representative of the
accessibility in the specific product.

AWK





> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Hoffman, Allen
> Sent: Thursday, September 20, 2007 11:43 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> All:
>
> Several people have raised questions related to how provisions in 8.1
> relate to other sections. I think I'd like to propose an update to
> the draft for 09/14 to include some intro materials to alleviate this
> concern, as it is obvious some connection is needed to make this
> self-evident.
>
> So:
>
> Sections 3 and 6 above require that information delivered must be
> presented meeting accessibility requirements. To accomplish this,
> information storage formats must allow for inclusion of certain
> accessibility related attributes and/or functionalities. This section

> describes the functional accessibility requirements for such formats.
> When determining the most accessible product from a set of more than
> one, the format information is provided in can determine if other
> requirements can be met or not, and can be an important factor in the
> final determination. Note:
> Formats which do not include some functionalities such as the ability
> to represent synchronized media, would not be subject to that
> provision.
>
>
>

From: Hoffman, Allen
Date: Thu, Sep 20 2007 11:30 AM
Subject: Re: intro for 8.1?

sorry I missed part of your email:

How do you envision the support for the content formats being defined?
Does each content format have a VPAT? If so, who writes it?

Just as a solution provider who provides products from a 3rd party
provides the government a VPAT for those items, (or should), when
solutions providers provide information products to the government they
should provide VPATS for those formats they plan to deliver. Open
formats may pose a greater challenge, but from examining the
specification, or from 3rd party sources open formats can be documented
effectively once a need is clearly known.

In cases where the government defines the format to be used as it
regularly does, this requirement would simply be a non-starter or not a
selection factor for all involved in an acquisition. Government does
such things all the time based on as-is architecture etc.

Another point for 8.1 section is that it defines the functionalities for
the underlying data storage schemas which relate to achieving
accessibility. this is important for internal "use" also, since Section
508 is NOT just for acquisitions, but is used for internally developed
items within the government. Use of 8.1 would lead internal developers
to selection of more accessible formats over time.






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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andrew
Kirkpatrick
Sent: Thursday, September 20, 2007 1:04 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] intro for 8.1?

Allen,

You state "When determining the most accessible product from a set of
more than one, the format information is provided in can determine if
other requirements can be met or not" but just because a format includes
support for a particular standard it doesn't mean that the product that
uses that format takes advantage of that support.

How do you envision the support for the content formats being defined?
Does each content format have a VPAT? If so, who writes it?

Part of my concern with the implementation of this section is that the
product is already reporting on how they support standards that overlap
with the content format items - I'm not sure that it will actually help
in procurement decisions since the product needs to meet the section 3
standards, and the section 8 standards not only don't bring anything new
to the picture but they are not necessarily representative of the
accessibility in the specific product.

AWK





> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Hoffman, Allen
> Sent: Thursday, September 20, 2007 11:43 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> All:
>
> Several people have raised questions related to how provisions in 8.1
> relate to other sections. I think I'd like to propose an update to
> the draft for 09/14 to include some intro materials to alleviate this
> concern, as it is obvious some connection is needed to make this
> self-evident.
>
> So:
>
> Sections 3 and 6 above require that information delivered must be
> presented meeting accessibility requirements. To accomplish this,
> information storage formats must allow for inclusion of certain
> accessibility related attributes and/or functionalities. This section

> describes the functional accessibility requirements for such formats.
> When determining the most accessible product from a set of more than
> one, the format information is provided in can determine if other
> requirements can be met or not, and can be an important factor in the
> final determination. Note:
> Formats which do not include some functionalities such as the ability
> to represent synchronized media, would not be subject to that
> provision.
>
>
>

From: James Elekes
Date: Thu, Sep 20 2007 11:55 AM
Subject: Re: intro for 8.1?

Jim and Allan,

From Board perspective, for ease of "readibility" shouldn't the
intro be standardized and be applicable to all sections in the most
general/simplest of terms? While Allan's material is precise, I
wonder how the Board's Committee/Staff and, those reading the NPRM
(once published) might perceive a certain lack of continuity if
information is only provided for certain sections.

Sorry if I'm missing something. Just trying to lay/establish ground
work for Board and, steps beyond once TEITAC Recommendations are received.

-Jim E.

James J. Elekes, Chairman
Telecommunications, Electronic/Information Technologies Committee
United States Access Board

At 12:34 PM 9/20/2007, you wrote:
>Thanks, Allen -- this is an important and necessary addition. We should
>probably draft similar introductions for other sections, wherver there may
>be doubt as to how to apply provisions.
>
>***
>Jim Tobias
>Inclusive Technologies
>+1.732.441.0831 v/tty
>+1.908.907.2387 mobile
>skype jimtobias
>
>
> > -----Original Message-----
> > From: Hoffman, Allen [mailto: = EMAIL ADDRESS REMOVED = ]
> > Sent: Thursday, September 20, 2007 11:43 AM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > All:
> >
> > Several people have raised questions related to how
> > provisions in 8.1 relate to other sections. I think I'd like
> > to propose an update to the draft for 09/14 to include some
> > intro materials to alleviate this concern, as it is obvious
> > some connection is needed to make this self-evident.
> >
> > So:
> >
> > Sections 3 and 6 above require that information delivered
> > must be presented meeting accessibility requirements. To
> > accomplish this, information storage formats must allow for
> > inclusion of certain accessibility related attributes and/or
> > functionalities. This section describes the functional
> > accessibility requirements for such formats.
> > When determining the most accessible product from a set of
> > more than one, the format information is provided in can
> > determine if other requirements can be met or not, and can be
> > an important factor in the final determination. Note:
> > Formats which do not include some functionalities such as the
> > ability to represent synchronized media, would not be subject
> > to that provision.
> >
> >
> >

From: James Elekes
Date: Thu, Sep 20 2007 12:00 PM
Subject: Re: intro for 8.1?

Allan,

Ok. See your point. My previous comment didn't consider materials
shared since initial communication early this morning.

Thanks, Jim E.


At 01:06 PM 9/20/2007, you wrote:
>Look at it as a sanity check.
>If you state that, for example, you meet the language requirement in 3,
>but select a format that doesn't include that capacity, something is
>wrong.
>
>
>
>Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
>-----Original Message-----
>From: = EMAIL ADDRESS REMOVED =
>[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andrew
>Kirkpatrick
>Sent: Thursday, September 20, 2007 1:04 PM
>To: TEITAC Web/Software Subcommittee
>Subject: Re: [teitac-websoftware] intro for 8.1?
>
>Allen,
>
>You state "When determining the most accessible product from a set of
>more than one, the format information is provided in can determine if
>other requirements can be met or not" but just because a format includes
>support for a particular standard it doesn't mean that the product that
>uses that format takes advantage of that support.
>
>How do you envision the support for the content formats being defined?
>Does each content format have a VPAT? If so, who writes it?
>
>Part of my concern with the implementation of this section is that the
>product is already reporting on how they support standards that overlap
>with the content format items - I'm not sure that it will actually help
>in procurement decisions since the product needs to meet the section 3
>standards, and the section 8 standards not only don't bring anything new
>to the picture but they are not necessarily representative of the
>accessibility in the specific product.
>
>AWK
>
>
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > Hoffman, Allen
> > Sent: Thursday, September 20, 2007 11:43 AM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > All:
> >
> > Several people have raised questions related to how provisions in 8.1
> > relate to other sections. I think I'd like to propose an update to
> > the draft for 09/14 to include some intro materials to alleviate this
> > concern, as it is obvious some connection is needed to make this
> > self-evident.
> >
> > So:
> >
> > Sections 3 and 6 above require that information delivered must be
> > presented meeting accessibility requirements. To accomplish this,
> > information storage formats must allow for inclusion of certain
> > accessibility related attributes and/or functionalities. This section
>
> > describes the functional accessibility requirements for such formats.
> > When determining the most accessible product from a set of more than
> > one, the format information is provided in can determine if other
> > requirements can be met or not, and can be an important factor in the
> > final determination. Note:
> > Formats which do not include some functionalities such as the ability
> > to represent synchronized media, would not be subject to that
> > provision.
> >
> >
> >

From: Andrew Kirkpatrick
Date: Thu, Sep 20 2007 12:40 PM
Subject: Re: intro for 8.1?

This seems like a lot of additional overhead for a mere sanity check.
I'm envisioning a lot of confusion for procurement people when they
receive a 16 page VPAT for a product that outputs in 5 different formats
and needs to include information about the capabilities of the format
for each. Do you really expect that these people will cross-reference
the product section 3 VPAT information against the various section 8
items for the format because it might reveal that the product VPAT
author is declaring something that they shouldn't?

AWK


> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Hoffman, Allen
> Sent: Thursday, September 20, 2007 1:07 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Look at it as a sanity check.
> If you state that, for example, you meet the language
> requirement in 3, but select a format that doesn't include
> that capacity, something is wrong.
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Andrew Kirkpatrick
> Sent: Thursday, September 20, 2007 1:04 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Allen,
>
> You state "When determining the most accessible product from
> a set of more than one, the format information is provided in
> can determine if other requirements can be met or not" but
> just because a format includes support for a particular
> standard it doesn't mean that the product that uses that
> format takes advantage of that support.
>
> How do you envision the support for the content formats being defined?
> Does each content format have a VPAT? If so, who writes it?
>
> Part of my concern with the implementation of this section is
> that the product is already reporting on how they support
> standards that overlap with the content format items - I'm
> not sure that it will actually help in procurement decisions
> since the product needs to meet the section 3 standards, and
> the section 8 standards not only don't bring anything new to
> the picture but they are not necessarily representative of
> the accessibility in the specific product.
>
> AWK
>
>
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > Hoffman, Allen
> > Sent: Thursday, September 20, 2007 11:43 AM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > All:
> >
> > Several people have raised questions related to how
> provisions in 8.1
> > relate to other sections. I think I'd like to propose an update to
> > the draft for 09/14 to include some intro materials to
> alleviate this
> > concern, as it is obvious some connection is needed to make this
> > self-evident.
> >
> > So:
> >
> > Sections 3 and 6 above require that information delivered must be
> > presented meeting accessibility requirements. To accomplish this,
> > information storage formats must allow for inclusion of certain
> > accessibility related attributes and/or functionalities.
> This section
>
> > describes the functional accessibility requirements for
> such formats.
> > When determining the most accessible product from a set of
> more than
> > one, the format information is provided in can determine if other
> > requirements can be met or not, and can be an important
> factor in the
> > final determination. Note:
> > Formats which do not include some functionalities such as
> the ability
> > to represent synchronized media, would not be subject to that
> > provision.
> >
> >
> >

From: Hoffman, Allen
Date: Thu, Sep 20 2007 12:45 PM
Subject: Re: intro for 8.1?

Point taken.
Let me consider a bit and will post with a walk through of how this can
work.



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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andrew
Kirkpatrick
Sent: Thursday, September 20, 2007 2:36 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] intro for 8.1?

This seems like a lot of additional overhead for a mere sanity check.
I'm envisioning a lot of confusion for procurement people when they
receive a 16 page VPAT for a product that outputs in 5 different formats
and needs to include information about the capabilities of the format
for each. Do you really expect that these people will cross-reference
the product section 3 VPAT information against the various section 8
items for the format because it might reveal that the product VPAT
author is declaring something that they shouldn't?

AWK


> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Hoffman, Allen
> Sent: Thursday, September 20, 2007 1:07 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Look at it as a sanity check.
> If you state that, for example, you meet the language requirement in
> 3, but select a format that doesn't include that capacity, something
> is wrong.
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Andrew Kirkpatrick
> Sent: Thursday, September 20, 2007 1:04 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Allen,
>
> You state "When determining the most accessible product from a set of
> more than one, the format information is provided in can determine if
> other requirements can be met or not" but just because a format
> includes support for a particular standard it doesn't mean that the
> product that uses that format takes advantage of that support.
>
> How do you envision the support for the content formats being defined?
> Does each content format have a VPAT? If so, who writes it?
>
> Part of my concern with the implementation of this section is that the

> product is already reporting on how they support standards that
> overlap with the content format items - I'm not sure that it will
> actually help in procurement decisions since the product needs to meet

> the section 3 standards, and the section 8 standards not only don't
> bring anything new to the picture but they are not necessarily
> representative of the accessibility in the specific product.
>
> AWK
>
>
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > Hoffman, Allen
> > Sent: Thursday, September 20, 2007 11:43 AM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > All:
> >
> > Several people have raised questions related to how
> provisions in 8.1
> > relate to other sections. I think I'd like to propose an update to
> > the draft for 09/14 to include some intro materials to
> alleviate this
> > concern, as it is obvious some connection is needed to make this
> > self-evident.
> >
> > So:
> >
> > Sections 3 and 6 above require that information delivered must be
> > presented meeting accessibility requirements. To accomplish this,
> > information storage formats must allow for inclusion of certain
> > accessibility related attributes and/or functionalities.
> This section
>
> > describes the functional accessibility requirements for
> such formats.
> > When determining the most accessible product from a set of
> more than
> > one, the format information is provided in can determine if other
> > requirements can be met or not, and can be an important
> factor in the
> > final determination. Note:
> > Formats which do not include some functionalities such as
> the ability
> > to represent synchronized media, would not be subject to that
> > provision.
> >
> >
> >

From: Jim Tobias
Date: Thu, Sep 20 2007 1:35 PM
Subject: Re: intro for 8.1?

I don't see why the entire format info would have to be in a VPAT if it's a
public, standard format used by the authoring tool in a standard way. If
the tool deviates from the format in any important way that would have to be
documented.

Am I missing something?

***
Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias


> -----Original Message-----
> From: Hoffman, Allen [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Thursday, September 20, 2007 2:39 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Point taken.
> Let me consider a bit and will post with a walk through of
> how this can work.
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Andrew Kirkpatrick
> Sent: Thursday, September 20, 2007 2:36 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> This seems like a lot of additional overhead for a mere sanity check.
> I'm envisioning a lot of confusion for procurement people
> when they receive a 16 page VPAT for a product that outputs
> in 5 different formats and needs to include information about
> the capabilities of the format for each. Do you really
> expect that these people will cross-reference the product
> section 3 VPAT information against the various section 8
> items for the format because it might reveal that the product
> VPAT author is declaring something that they shouldn't?
>
> AWK
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > Hoffman, Allen
> > Sent: Thursday, September 20, 2007 1:07 PM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > Look at it as a sanity check.
> > If you state that, for example, you meet the language
> requirement in
> > 3, but select a format that doesn't include that capacity,
> something
> > is wrong.
> >
> >
> >
> > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > Andrew Kirkpatrick
> > Sent: Thursday, September 20, 2007 1:04 PM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > Allen,
> >
> > You state "When determining the most accessible product
> from a set of
> > more than one, the format information is provided in can
> determine if
> > other requirements can be met or not" but just because a format
> > includes support for a particular standard it doesn't mean that the
> > product that uses that format takes advantage of that support.
> >
> > How do you envision the support for the content formats
> being defined?
> > Does each content format have a VPAT? If so, who writes it?
> >
> > Part of my concern with the implementation of this section
> is that the
>
> > product is already reporting on how they support standards that
> > overlap with the content format items - I'm not sure that it will
> > actually help in procurement decisions since the product
> needs to meet
>
> > the section 3 standards, and the section 8 standards not only don't
> > bring anything new to the picture but they are not necessarily
> > representative of the accessibility in the specific product.
> >
> > AWK
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > > Hoffman, Allen
> > > Sent: Thursday, September 20, 2007 11:43 AM
> > > To: TEITAC Web/Software Subcommittee
> > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > >
> > > All:
> > >
> > > Several people have raised questions related to how
> > provisions in 8.1
> > > relate to other sections. I think I'd like to propose an
> update to
> > > the draft for 09/14 to include some intro materials to
> > alleviate this
> > > concern, as it is obvious some connection is needed to make this
> > > self-evident.
> > >
> > > So:
> > >
> > > Sections 3 and 6 above require that information delivered must be
> > > presented meeting accessibility requirements. To
> accomplish this,
> > > information storage formats must allow for inclusion of certain
> > > accessibility related attributes and/or functionalities.
> > This section
> >
> > > describes the functional accessibility requirements for
> > such formats.
> > > When determining the most accessible product from a set of
> > more than
> > > one, the format information is provided in can determine if other
> > > requirements can be met or not, and can be an important
> > factor in the
> > > final determination. Note:
> > > Formats which do not include some functionalities such as
> > the ability
> > > to represent synchronized media, would not be subject to that
> > > provision.
> > >
> > >
> > >

From: Andrew Kirkpatrick
Date: Thu, Sep 20 2007 2:40 PM
Subject: Re: intro for 8.1?

This is part of what I'm asking.

Also a part of what I'm asking is due to differences in what products
support. A product may not use all of the accessibility features in a
format, and more specifically, a product may not need to use all of the
support available in a format, depending on the use of the product.
Imagine a format that complies with everything except the format doesn't
allow for equivalents for images. If a government agency knows that the
product doesn't create images in its output, even though the format
doesn't support this, it doesn't matter for that product - what is
important is the output of the product.

AWK

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Jim Tobias
> Sent: Thursday, September 20, 2007 3:31 PM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> I don't see why the entire format info would have to be in a
> VPAT if it's a public, standard format used by the authoring
> tool in a standard way. If the tool deviates from the format
> in any important way that would have to be documented.
>
> Am I missing something?
>
> ***
> Jim Tobias
> Inclusive Technologies
> +1.732.441.0831 v/tty
> +1.908.907.2387 mobile
> skype jimtobias
>
>
> > -----Original Message-----
> > From: Hoffman, Allen [mailto: = EMAIL ADDRESS REMOVED = ]
> > Sent: Thursday, September 20, 2007 2:39 PM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > Point taken.
> > Let me consider a bit and will post with a walk through of how this
> > can work.
> >
> >
> >
> > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > Andrew Kirkpatrick
> > Sent: Thursday, September 20, 2007 2:36 PM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > This seems like a lot of additional overhead for a mere
> sanity check.
> > I'm envisioning a lot of confusion for procurement people when they
> > receive a 16 page VPAT for a product that outputs in 5 different
> > formats and needs to include information about the
> capabilities of the
> > format for each. Do you really expect that these people will
> > cross-reference the product section 3 VPAT information against the
> > various section 8 items for the format because it might reveal that
> > the product VPAT author is declaring something that they shouldn't?
> >
> > AWK
> >
> >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > > Hoffman, Allen
> > > Sent: Thursday, September 20, 2007 1:07 PM
> > > To: TEITAC Web/Software Subcommittee
> > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > >
> > > Look at it as a sanity check.
> > > If you state that, for example, you meet the language
> > requirement in
> > > 3, but select a format that doesn't include that capacity,
> > something
> > > is wrong.
> > >
> > >
> > >
> > > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> > >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > > Andrew Kirkpatrick
> > > Sent: Thursday, September 20, 2007 1:04 PM
> > > To: TEITAC Web/Software Subcommittee
> > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > >
> > > Allen,
> > >
> > > You state "When determining the most accessible product
> > from a set of
> > > more than one, the format information is provided in can
> > determine if
> > > other requirements can be met or not" but just because a format
> > > includes support for a particular standard it doesn't
> mean that the
> > > product that uses that format takes advantage of that support.
> > >
> > > How do you envision the support for the content formats
> > being defined?
> > > Does each content format have a VPAT? If so, who writes it?
> > >
> > > Part of my concern with the implementation of this section
> > is that the
> >
> > > product is already reporting on how they support standards that
> > > overlap with the content format items - I'm not sure that it will
> > > actually help in procurement decisions since the product
> > needs to meet
> >
> > > the section 3 standards, and the section 8 standards not
> only don't
> > > bring anything new to the picture but they are not necessarily
> > > representative of the accessibility in the specific product.
> > >
> > > AWK
> > >
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: = EMAIL ADDRESS REMOVED =
> > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of
> > > > Hoffman, Allen
> > > > Sent: Thursday, September 20, 2007 11:43 AM
> > > > To: TEITAC Web/Software Subcommittee
> > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > >
> > > > All:
> > > >
> > > > Several people have raised questions related to how
> > > provisions in 8.1
> > > > relate to other sections. I think I'd like to propose an
> > update to
> > > > the draft for 09/14 to include some intro materials to
> > > alleviate this
> > > > concern, as it is obvious some connection is needed to
> make this
> > > > self-evident.
> > > >
> > > > So:
> > > >
> > > > Sections 3 and 6 above require that information
> delivered must be
> > > > presented meeting accessibility requirements. To
> > accomplish this,
> > > > information storage formats must allow for inclusion of certain
> > > > accessibility related attributes and/or functionalities.
> > > This section
> > >
> > > > describes the functional accessibility requirements for
> > > such formats.
> > > > When determining the most accessible product from a set of
> > > more than
> > > > one, the format information is provided in can
> determine if other
> > > > requirements can be met or not, and can be an important
> > > factor in the
> > > > final determination. Note:
> > > > Formats which do not include some functionalities such as
> > > the ability
> > > > to represent synchronized media, would not be subject to that
> > > > provision.
> > > >
> > > >
> > > >

From: Hoffman, Allen
Date: Fri, Sep 21 2007 6:05 AM
Subject: Re: intro for 8.1?

I think we're talking chicken and egg kinds of things.

A can't do B if A doesn't allow for B.
if you don't need B, its not important--but knowing what A can and can't
do is important. -- channeling some Sean Hayes here.




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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andrew
Kirkpatrick
Sent: Thursday, September 20, 2007 4:39 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] intro for 8.1?

This is part of what I'm asking.

Also a part of what I'm asking is due to differences in what products
support. A product may not use all of the accessibility features in a
format, and more specifically, a product may not need to use all of the
support available in a format, depending on the use of the product.
Imagine a format that complies with everything except the format doesn't
allow for equivalents for images. If a government agency knows that the
product doesn't create images in its output, even though the format
doesn't support this, it doesn't matter for that product - what is
important is the output of the product.

AWK

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim
> Tobias
> Sent: Thursday, September 20, 2007 3:31 PM
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> I don't see why the entire format info would have to be in a VPAT if
> it's a public, standard format used by the authoring tool in a
> standard way. If the tool deviates from the format in any important
> way that would have to be documented.
>
> Am I missing something?
>
> ***
> Jim Tobias
> Inclusive Technologies
> +1.732.441.0831 v/tty
> +1.908.907.2387 mobile
> skype jimtobias
>
>
> > -----Original Message-----
> > From: Hoffman, Allen [mailto: = EMAIL ADDRESS REMOVED = ]
> > Sent: Thursday, September 20, 2007 2:39 PM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > Point taken.
> > Let me consider a bit and will post with a walk through of how this
> > can work.
> >
> >
> >
> > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > Andrew Kirkpatrick
> > Sent: Thursday, September 20, 2007 2:36 PM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > This seems like a lot of additional overhead for a mere
> sanity check.
> > I'm envisioning a lot of confusion for procurement people when they
> > receive a 16 page VPAT for a product that outputs in 5 different
> > formats and needs to include information about the
> capabilities of the
> > format for each. Do you really expect that these people will
> > cross-reference the product section 3 VPAT information against the
> > various section 8 items for the format because it might reveal that
> > the product VPAT author is declaring something that they shouldn't?
> >
> > AWK
> >
> >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > > Hoffman, Allen
> > > Sent: Thursday, September 20, 2007 1:07 PM
> > > To: TEITAC Web/Software Subcommittee
> > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > >
> > > Look at it as a sanity check.
> > > If you state that, for example, you meet the language
> > requirement in
> > > 3, but select a format that doesn't include that capacity,
> > something
> > > is wrong.
> > >
> > >
> > >
> > > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> > >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > > Andrew Kirkpatrick
> > > Sent: Thursday, September 20, 2007 1:04 PM
> > > To: TEITAC Web/Software Subcommittee
> > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > >
> > > Allen,
> > >
> > > You state "When determining the most accessible product
> > from a set of
> > > more than one, the format information is provided in can
> > determine if
> > > other requirements can be met or not" but just because a format
> > > includes support for a particular standard it doesn't
> mean that the
> > > product that uses that format takes advantage of that support.
> > >
> > > How do you envision the support for the content formats
> > being defined?
> > > Does each content format have a VPAT? If so, who writes it?
> > >
> > > Part of my concern with the implementation of this section
> > is that the
> >
> > > product is already reporting on how they support standards that
> > > overlap with the content format items - I'm not sure that it will
> > > actually help in procurement decisions since the product
> > needs to meet
> >
> > > the section 3 standards, and the section 8 standards not
> only don't
> > > bring anything new to the picture but they are not necessarily
> > > representative of the accessibility in the specific product.
> > >
> > > AWK
> > >
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: = EMAIL ADDRESS REMOVED =
> > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of
> > > > Hoffman, Allen
> > > > Sent: Thursday, September 20, 2007 11:43 AM
> > > > To: TEITAC Web/Software Subcommittee
> > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > >
> > > > All:
> > > >
> > > > Several people have raised questions related to how
> > > provisions in 8.1
> > > > relate to other sections. I think I'd like to propose an
> > update to
> > > > the draft for 09/14 to include some intro materials to
> > > alleviate this
> > > > concern, as it is obvious some connection is needed to
> make this
> > > > self-evident.
> > > >
> > > > So:
> > > >
> > > > Sections 3 and 6 above require that information
> delivered must be
> > > > presented meeting accessibility requirements. To
> > accomplish this,
> > > > information storage formats must allow for inclusion of certain
> > > > accessibility related attributes and/or functionalities.
> > > This section
> > >
> > > > describes the functional accessibility requirements for
> > > such formats.
> > > > When determining the most accessible product from a set of
> > > more than
> > > > one, the format information is provided in can
> determine if other
> > > > requirements can be met or not, and can be an important
> > > factor in the
> > > > final determination. Note:
> > > > Formats which do not include some functionalities such as
> > > the ability
> > > > to represent synchronized media, would not be subject to that
> > > > provision.
> > > >
> > > >
> > > >

From: Andrew Kirkpatrick
Date: Fri, Sep 21 2007 7:50 AM
Subject: Re: intro for 8.1?

Allen,
I'm sorry, but your message is just a little too cryptic for me to
follow. Can you fill in "a" and "b" with actual items?
Thanks,
AWK



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Hoffman, Allen
> Sent: Friday, September 21, 2007 8:01 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> I think we're talking chicken and egg kinds of things.
>
> A can't do B if A doesn't allow for B.
> if you don't need B, its not important--but knowing what A
> can and can't do is important. -- channeling some Sean Hayes here.
>
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Andrew Kirkpatrick
> Sent: Thursday, September 20, 2007 4:39 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> This is part of what I'm asking.
>
> Also a part of what I'm asking is due to differences in what
> products support. A product may not use all of the
> accessibility features in a format, and more specifically, a
> product may not need to use all of the support available in a
> format, depending on the use of the product.
> Imagine a format that complies with everything except the
> format doesn't allow for equivalents for images. If a
> government agency knows that the product doesn't create
> images in its output, even though the format doesn't support
> this, it doesn't matter for that product - what is important
> is the output of the product.
>
> AWK
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> > Tobias
> > Sent: Thursday, September 20, 2007 3:31 PM
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > I don't see why the entire format info would have to be in
> a VPAT if
> > it's a public, standard format used by the authoring tool in a
> > standard way. If the tool deviates from the format in any
> important
> > way that would have to be documented.
> >
> > Am I missing something?
> >
> > ***
> > Jim Tobias
> > Inclusive Technologies
> > +1.732.441.0831 v/tty
> > +1.908.907.2387 mobile
> > skype jimtobias
> >
> >
> > > -----Original Message-----
> > > From: Hoffman, Allen [mailto: = EMAIL ADDRESS REMOVED = ]
> > > Sent: Thursday, September 20, 2007 2:39 PM
> > > To: TEITAC Web/Software Subcommittee
> > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > >
> > > Point taken.
> > > Let me consider a bit and will post with a walk through
> of how this
> > > can work.
> > >
> > >
> > >
> > > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> > >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > > Andrew Kirkpatrick
> > > Sent: Thursday, September 20, 2007 2:36 PM
> > > To: TEITAC Web/Software Subcommittee
> > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > >
> > > This seems like a lot of additional overhead for a mere
> > sanity check.
> > > I'm envisioning a lot of confusion for procurement people
> when they
> > > receive a 16 page VPAT for a product that outputs in 5 different
> > > formats and needs to include information about the
> > capabilities of the
> > > format for each. Do you really expect that these people will
> > > cross-reference the product section 3 VPAT information
> against the
> > > various section 8 items for the format because it might
> reveal that
> > > the product VPAT author is declaring something that they
> shouldn't?
> > >
> > > AWK
> > >
> > >
> > > > -----Original Message-----
> > > > From: = EMAIL ADDRESS REMOVED =
> > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of
> > > > Hoffman, Allen
> > > > Sent: Thursday, September 20, 2007 1:07 PM
> > > > To: TEITAC Web/Software Subcommittee
> > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > >
> > > > Look at it as a sanity check.
> > > > If you state that, for example, you meet the language
> > > requirement in
> > > > 3, but select a format that doesn't include that capacity,
> > > something
> > > > is wrong.
> > > >
> > > >
> > > >
> > > > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> > > >
> > > > -----Original Message-----
> > > > From: = EMAIL ADDRESS REMOVED =
> > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of
> > > > Andrew Kirkpatrick
> > > > Sent: Thursday, September 20, 2007 1:04 PM
> > > > To: TEITAC Web/Software Subcommittee
> > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > >
> > > > Allen,
> > > >
> > > > You state "When determining the most accessible product
> > > from a set of
> > > > more than one, the format information is provided in can
> > > determine if
> > > > other requirements can be met or not" but just because a format
> > > > includes support for a particular standard it doesn't
> > mean that the
> > > > product that uses that format takes advantage of that support.
> > > >
> > > > How do you envision the support for the content formats
> > > being defined?
> > > > Does each content format have a VPAT? If so, who writes it?
> > > >
> > > > Part of my concern with the implementation of this section
> > > is that the
> > >
> > > > product is already reporting on how they support standards that
> > > > overlap with the content format items - I'm not sure
> that it will
> > > > actually help in procurement decisions since the product
> > > needs to meet
> > >
> > > > the section 3 standards, and the section 8 standards not
> > only don't
> > > > bring anything new to the picture but they are not necessarily
> > > > representative of the accessibility in the specific product.
> > > >
> > > > AWK
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: = EMAIL ADDRESS REMOVED =
> > > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> > Behalf Of
> > > > > Hoffman, Allen
> > > > > Sent: Thursday, September 20, 2007 11:43 AM
> > > > > To: TEITAC Web/Software Subcommittee
> > > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > > >
> > > > > All:
> > > > >
> > > > > Several people have raised questions related to how
> > > > provisions in 8.1
> > > > > relate to other sections. I think I'd like to propose an
> > > update to
> > > > > the draft for 09/14 to include some intro materials to
> > > > alleviate this
> > > > > concern, as it is obvious some connection is needed to
> > make this
> > > > > self-evident.
> > > > >
> > > > > So:
> > > > >
> > > > > Sections 3 and 6 above require that information
> > delivered must be
> > > > > presented meeting accessibility requirements. To
> > > accomplish this,
> > > > > information storage formats must allow for inclusion
> of certain
> > > > > accessibility related attributes and/or functionalities.
> > > > This section
> > > >
> > > > > describes the functional accessibility requirements for
> > > > such formats.
> > > > > When determining the most accessible product from a set of
> > > > more than
> > > > > one, the format information is provided in can
> > determine if other
> > > > > requirements can be met or not, and can be an important
> > > > factor in the
> > > > > final determination. Note:
> > > > > Formats which do not include some functionalities such as
> > > > the ability
> > > > > to represent synchronized media, would not be subject to that
> > > > > provision.
> > > > >
> > > > >
> > > > >

From: Hoffman, Allen
Date: Fri, Sep 21 2007 9:10 AM
Subject: Re: intro for 8.1?

Chicken and egg:

(a) is format, b is deliverable and/or document.

So, if (format) can't store or represent, just as an example, text for
images, then document (b) that uses images won't be able to be compliant
for that requirement. so if a deliverable is represented as compliant,
but is in a underlying format that won't support the ability to comply
with a requirement, we know there is a problem somewhere.

The idea is to drive people to formats that can support more
accessibility over less, just as we do for other EIT. currently we
often get the push back that we can't comply because the format won't do
what you need, and "we have to use that format". This format
preselection is usually a false business need. Most of us don't have a
business need to use only one format. sometimes we do but the format
selection decision should not be made in a vacuum as it bears directly
on the accessibility of the end products so greatly.




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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andrew
Kirkpatrick
Sent: Friday, September 21, 2007 9:46 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] intro for 8.1?

Allen,
I'm sorry, but your message is just a little too cryptic for me to
follow. Can you fill in "a" and "b" with actual items?
Thanks,
AWK



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Hoffman, Allen
> Sent: Friday, September 21, 2007 8:01 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> I think we're talking chicken and egg kinds of things.
>
> A can't do B if A doesn't allow for B.
> if you don't need B, its not important--but knowing what A can and
> can't do is important. -- channeling some Sean Hayes here.
>
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Andrew Kirkpatrick
> Sent: Thursday, September 20, 2007 4:39 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> This is part of what I'm asking.
>
> Also a part of what I'm asking is due to differences in what products
> support. A product may not use all of the accessibility features in a

> format, and more specifically, a product may not need to use all of
> the support available in a format, depending on the use of the
> product.
> Imagine a format that complies with everything except the format
> doesn't allow for equivalents for images. If a government agency
> knows that the product doesn't create images in its output, even
> though the format doesn't support this, it doesn't matter for that
> product - what is important is the output of the product.
>
> AWK
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> > Tobias
> > Sent: Thursday, September 20, 2007 3:31 PM
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > I don't see why the entire format info would have to be in
> a VPAT if
> > it's a public, standard format used by the authoring tool in a
> > standard way. If the tool deviates from the format in any
> important
> > way that would have to be documented.
> >
> > Am I missing something?
> >
> > ***
> > Jim Tobias
> > Inclusive Technologies
> > +1.732.441.0831 v/tty
> > +1.908.907.2387 mobile
> > skype jimtobias
> >
> >
> > > -----Original Message-----
> > > From: Hoffman, Allen [mailto: = EMAIL ADDRESS REMOVED = ]
> > > Sent: Thursday, September 20, 2007 2:39 PM
> > > To: TEITAC Web/Software Subcommittee
> > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > >
> > > Point taken.
> > > Let me consider a bit and will post with a walk through
> of how this
> > > can work.
> > >
> > >
> > >
> > > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> > >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > > Andrew Kirkpatrick
> > > Sent: Thursday, September 20, 2007 2:36 PM
> > > To: TEITAC Web/Software Subcommittee
> > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > >
> > > This seems like a lot of additional overhead for a mere
> > sanity check.
> > > I'm envisioning a lot of confusion for procurement people
> when they
> > > receive a 16 page VPAT for a product that outputs in 5 different
> > > formats and needs to include information about the
> > capabilities of the
> > > format for each. Do you really expect that these people will
> > > cross-reference the product section 3 VPAT information
> against the
> > > various section 8 items for the format because it might
> reveal that
> > > the product VPAT author is declaring something that they
> shouldn't?
> > >
> > > AWK
> > >
> > >
> > > > -----Original Message-----
> > > > From: = EMAIL ADDRESS REMOVED =
> > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of
> > > > Hoffman, Allen
> > > > Sent: Thursday, September 20, 2007 1:07 PM
> > > > To: TEITAC Web/Software Subcommittee
> > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > >
> > > > Look at it as a sanity check.
> > > > If you state that, for example, you meet the language
> > > requirement in
> > > > 3, but select a format that doesn't include that capacity,
> > > something
> > > > is wrong.
> > > >
> > > >
> > > >
> > > > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> > > >
> > > > -----Original Message-----
> > > > From: = EMAIL ADDRESS REMOVED =
> > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of
> > > > Andrew Kirkpatrick
> > > > Sent: Thursday, September 20, 2007 1:04 PM
> > > > To: TEITAC Web/Software Subcommittee
> > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > >
> > > > Allen,
> > > >
> > > > You state "When determining the most accessible product
> > > from a set of
> > > > more than one, the format information is provided in can
> > > determine if
> > > > other requirements can be met or not" but just because a format
> > > > includes support for a particular standard it doesn't
> > mean that the
> > > > product that uses that format takes advantage of that support.
> > > >
> > > > How do you envision the support for the content formats
> > > being defined?
> > > > Does each content format have a VPAT? If so, who writes it?
> > > >
> > > > Part of my concern with the implementation of this section
> > > is that the
> > >
> > > > product is already reporting on how they support standards that
> > > > overlap with the content format items - I'm not sure
> that it will
> > > > actually help in procurement decisions since the product
> > > needs to meet
> > >
> > > > the section 3 standards, and the section 8 standards not
> > only don't
> > > > bring anything new to the picture but they are not necessarily
> > > > representative of the accessibility in the specific product.
> > > >
> > > > AWK
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: = EMAIL ADDRESS REMOVED =
> > > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> > Behalf Of
> > > > > Hoffman, Allen
> > > > > Sent: Thursday, September 20, 2007 11:43 AM
> > > > > To: TEITAC Web/Software Subcommittee
> > > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > > >
> > > > > All:
> > > > >
> > > > > Several people have raised questions related to how
> > > > provisions in 8.1
> > > > > relate to other sections. I think I'd like to propose an
> > > update to
> > > > > the draft for 09/14 to include some intro materials to
> > > > alleviate this
> > > > > concern, as it is obvious some connection is needed to
> > make this
> > > > > self-evident.
> > > > >
> > > > > So:
> > > > >
> > > > > Sections 3 and 6 above require that information
> > delivered must be
> > > > > presented meeting accessibility requirements. To
> > > accomplish this,
> > > > > information storage formats must allow for inclusion
> of certain
> > > > > accessibility related attributes and/or functionalities.
> > > > This section
> > > >
> > > > > describes the functional accessibility requirements for
> > > > such formats.
> > > > > When determining the most accessible product from a set of
> > > > more than
> > > > > one, the format information is provided in can
> > determine if other
> > > > > requirements can be met or not, and can be an important
> > > > factor in the
> > > > > final determination. Note:
> > > > > Formats which do not include some functionalities such as
> > > > the ability
> > > > > to represent synchronized media, would not be subject to that
> > > > > provision.
> > > > >
> > > > >
> > > > >

From: Andrew Kirkpatrick
Date: Fri, Sep 21 2007 9:50 AM
Subject: Re: intro for 8.1?

> Chicken and egg:
>
> (a) is format, b is deliverable and/or document.
>
> So, if (format) can't store or represent, just as an example,
> text for images, then document (b) that uses images won't be
> able to be compliant for that requirement. so if a
> deliverable is represented as compliant, but is in a
> underlying format that won't support the ability to comply
> with a requirement, we know there is a problem somewhere.

I think that you are oversimplifying things. Formats may be able to be
extended, or aspects of formats where there are compliance issues may be
avoided.

If I'm writing support information for a format, can I claim compliance
if someone could possibly extend the format to add the support for a
standard that is not met in the base state for the format? I think that
no is the appropriate answer, but don't want to create additional
hurdles for the developer or procurement person since what matters is
whether the product that is being purchased is compliant.

So what we have is this:

- a procurement officer can verify that the section 8 claims for a
product are accurate by checking if the format that the product is in
has compliance information in section 3 that is in line with the section
8 claims, except that the product may be able to extend the base
"format" or the product may not use parts of the format that are not
fully compliant.

The section 8 format standards are completely covered by the section 3
software standards - this is extra effort without a meaningful return,
and it will either be ignored if not provided with the product VPAT or
add significantly to the confusion and work for procurement if it is.

That doesn't seem like enough to justify this extra set of standards.

AWK

From: Sean Hayes
Date: Fri, Sep 21 2007 10:00 AM
Subject: Re: intro for 8.1?

"So, if (format) can't store or represent, just as an example, text for
images, then document (b) that uses images won't be able to be compliant
for that requirement ".

Is too narrow a view of the requirement.

"When a content format supports non-text objects, an encoding mechanism shall be provided to associate non-text objects with textual descriptions displayable by a user-agent."

There is a higher level here. What is the task trying to achieve?

The requirement to associate text with images is there so that an individual that can't see the image can understand the content. The requirement really is that the both the image and the text exist, and the association between them is preserved so that when an arbitrary user comes across the image, they also get the text.

It is not necessarily a requirement that a format encode both the image and the text, or indeed the association.

For example GIF and HTML are both content formats. HTML does not encode the pixel data, GIF does not encode the text. It is the combination of the formats which provides the necessary information. The association is provided by the src and alt attributes, which in this case happens to be embedded in the HTML and the text is stored locally however this is not the only configuration which would work.

We could envision different systems, which would also fulfil the purpose of the task; for example a metadata database which can associate an image with the text for that image. The text might be in another resource entirely (e.g. a resource fork or a properties file). Or the text might be in metadata in the image itself.

Let us posit the GregorianDocumentFormat (GDF) which 'supports' a non-text media format by including a reference to it using its ISAN number.

Authors associate text for the media object by indexing the text in a data repository using the same ISAN, and storing the pixels for the media object in the same database using the same ISAN.

Thus GDF does not provide an encoding mechanism directly in terms of bits in the document, but an encoding mechanism is certainly provided. The GDF viewer software, if it can present the pixels can also present the text.

We can rephrase the requirement to avoid reference to a content format as follows:

"All non-text objects that are presented to the user must have a text alternative that presents equivalent information, except for the situations listed below."

Which is the non-text content provision for software. So the first content provision is in fact logically redundant.

This will also be true for all of the proposed content provisions.


Sean Hayes
Incubation Lab
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,
Mobile: +44 7875 091385


-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Hoffman, Allen
Sent: 21 September 2007 16:03
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] intro for 8.1?

Chicken and egg:

(a) is format, b is deliverable and/or document.

So, if (format) can't store or represent, just as an example, text for
images, then document (b) that uses images won't be able to be compliant
for that requirement. so if a deliverable is represented as compliant,
but is in a underlying format that won't support the ability to comply
with a requirement, we know there is a problem somewhere.

The idea is to drive people to formats that can support more
accessibility over less, just as we do for other EIT. currently we
often get the push back that we can't comply because the format won't do
what you need, and "we have to use that format". This format
preselection is usually a false business need. Most of us don't have a
business need to use only one format. sometimes we do but the format
selection decision should not be made in a vacuum as it bears directly
on the accessibility of the end products so greatly.




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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andrew
Kirkpatrick
Sent: Friday, September 21, 2007 9:46 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] intro for 8.1?

Allen,
I'm sorry, but your message is just a little too cryptic for me to
follow. Can you fill in "a" and "b" with actual items?
Thanks,
AWK



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Hoffman, Allen
> Sent: Friday, September 21, 2007 8:01 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> I think we're talking chicken and egg kinds of things.
>
> A can't do B if A doesn't allow for B.
> if you don't need B, its not important--but knowing what A can and
> can't do is important. -- channeling some Sean Hayes here.
>
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Andrew Kirkpatrick
> Sent: Thursday, September 20, 2007 4:39 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> This is part of what I'm asking.
>
> Also a part of what I'm asking is due to differences in what products
> support. A product may not use all of the accessibility features in a

> format, and more specifically, a product may not need to use all of
> the support available in a format, depending on the use of the
> product.
> Imagine a format that complies with everything except the format
> doesn't allow for equivalents for images. If a government agency
> knows that the product doesn't create images in its output, even
> though the format doesn't support this, it doesn't matter for that
> product - what is important is the output of the product.
>
> AWK
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> > Tobias
> > Sent: Thursday, September 20, 2007 3:31 PM
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > I don't see why the entire format info would have to be in
> a VPAT if
> > it's a public, standard format used by the authoring tool in a
> > standard way. If the tool deviates from the format in any
> important
> > way that would have to be documented.
> >
> > Am I missing something?
> >
> > ***
> > Jim Tobias
> > Inclusive Technologies
> > +1.732.441.0831 v/tty
> > +1.908.907.2387 mobile
> > skype jimtobias
> >
> >
> > > -----Original Message-----
> > > From: Hoffman, Allen [mailto: = EMAIL ADDRESS REMOVED = ]
> > > Sent: Thursday, September 20, 2007 2:39 PM
> > > To: TEITAC Web/Software Subcommittee
> > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > >
> > > Point taken.
> > > Let me consider a bit and will post with a walk through
> of how this
> > > can work.
> > >
> > >
> > >
> > > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> > >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > > Andrew Kirkpatrick
> > > Sent: Thursday, September 20, 2007 2:36 PM
> > > To: TEITAC Web/Software Subcommittee
> > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > >
> > > This seems like a lot of additional overhead for a mere
> > sanity check.
> > > I'm envisioning a lot of confusion for procurement people
> when they
> > > receive a 16 page VPAT for a product that outputs in 5 different
> > > formats and needs to include information about the
> > capabilities of the
> > > format for each. Do you really expect that these people will
> > > cross-reference the product section 3 VPAT information
> against the
> > > various section 8 items for the format because it might
> reveal that
> > > the product VPAT author is declaring something that they
> shouldn't?
> > >
> > > AWK
> > >
> > >
> > > > -----Original Message-----
> > > > From: = EMAIL ADDRESS REMOVED =
> > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of
> > > > Hoffman, Allen
> > > > Sent: Thursday, September 20, 2007 1:07 PM
> > > > To: TEITAC Web/Software Subcommittee
> > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > >
> > > > Look at it as a sanity check.
> > > > If you state that, for example, you meet the language
> > > requirement in
> > > > 3, but select a format that doesn't include that capacity,
> > > something
> > > > is wrong.
> > > >
> > > >
> > > >
> > > > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> > > >
> > > > -----Original Message-----
> > > > From: = EMAIL ADDRESS REMOVED =
> > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of
> > > > Andrew Kirkpatrick
> > > > Sent: Thursday, September 20, 2007 1:04 PM
> > > > To: TEITAC Web/Software Subcommittee
> > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > >
> > > > Allen,
> > > >
> > > > You state "When determining the most accessible product
> > > from a set of
> > > > more than one, the format information is provided in can
> > > determine if
> > > > other requirements can be met or not" but just because a format
> > > > includes support for a particular standard it doesn't
> > mean that the
> > > > product that uses that format takes advantage of that support.
> > > >
> > > > How do you envision the support for the content formats
> > > being defined?
> > > > Does each content format have a VPAT? If so, who writes it?
> > > >
> > > > Part of my concern with the implementation of this section
> > > is that the
> > >
> > > > product is already reporting on how they support standards that
> > > > overlap with the content format items - I'm not sure
> that it will
> > > > actually help in procurement decisions since the product
> > > needs to meet
> > >
> > > > the section 3 standards, and the section 8 standards not
> > only don't
> > > > bring anything new to the picture but they are not necessarily
> > > > representative of the accessibility in the specific product.
> > > >
> > > > AWK
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: = EMAIL ADDRESS REMOVED =
> > > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> > Behalf Of
> > > > > Hoffman, Allen
> > > > > Sent: Thursday, September 20, 2007 11:43 AM
> > > > > To: TEITAC Web/Software Subcommittee
> > > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > > >
> > > > > All:
> > > > >
> > > > > Several people have raised questions related to how
> > > > provisions in 8.1
> > > > > relate to other sections. I think I'd like to propose an
> > > update to
> > > > > the draft for 09/14 to include some intro materials to
> > > > alleviate this
> > > > > concern, as it is obvious some connection is needed to
> > make this
> > > > > self-evident.
> > > > >
> > > > > So:
> > > > >
> > > > > Sections 3 and 6 above require that information
> > delivered must be
> > > > > presented meeting accessibility requirements. To
> > > accomplish this,
> > > > > information storage formats must allow for inclusion
> of certain
> > > > > accessibility related attributes and/or functionalities.
> > > > This section
> > > >
> > > > > describes the functional accessibility requirements for
> > > > such formats.
> > > > > When determining the most accessible product from a set of
> > > > more than
> > > > > one, the format information is provided in can
> > determine if other
> > > > > requirements can be met or not, and can be an important
> > > > factor in the
> > > > > final determination. Note:
> > > > > Formats which do not include some functionalities such as
> > > > the ability
> > > > > to represent synchronized media, would not be subject to that
> > > > > provision.
> > > > >
> > > > >
> > > > >

From: Andi Snow-Weaver
Date: Fri, Sep 21 2007 11:25 AM
Subject: Re: intro for 8.1?

So Sean, are you proposing that we don't need the content format provisions
at all? I think that is also Andrew's point.

Andi




Sean Hayes
<Sean.Hayes@micro
soft.com> To
Sent by: TEITAC Web/Software Subcommittee
teitac-websoftwar < = EMAIL ADDRESS REMOVED =
= EMAIL ADDRESS REMOVED = >
itac.org cc

Subject
09/21/2007 10:55 Re: [teitac-websoftware] intro for
AM 8.1?


Please respond to
TEITAC
Web/Software
Subcommittee
<teitac-websoftwa
= EMAIL ADDRESS REMOVED =
g>






"So, if (format) can't store or represent, just as an example, text for
images, then document (b) that uses images won't be able to be compliant
for that requirement ".

Is too narrow a view of the requirement.

"When a content format supports non-text objects, an encoding mechanism
shall be provided to associate non-text objects with textual descriptions
displayable by a user-agent."

There is a higher level here. What is the task trying to achieve?

The requirement to associate text with images is there so that an
individual that can't see the image can understand the content. The
requirement really is that the both the image and the text exist, and the
association between them is preserved so that when an arbitrary user comes
across the image, they also get the text.

It is not necessarily a requirement that a format encode both the image and
the text, or indeed the association.

For example GIF and HTML are both content formats. HTML does not encode the
pixel data, GIF does not encode the text. It is the combination of the
formats which provides the necessary information. The association is
provided by the src and alt attributes, which in this case happens to be
embedded in the HTML and the text is stored locally however this is not the
only configuration which would work.

We could envision different systems, which would also fulfil the purpose of
the task; for example a metadata database which can associate an image with
the text for that image. The text might be in another resource entirely
(e.g. a resource fork or a properties file). Or the text might be in
metadata in the image itself.

Let us posit the GregorianDocumentFormat (GDF) which 'supports' a non-text
media format by including a reference to it using its ISAN number.

Authors associate text for the media object by indexing the text in a data
repository using the same ISAN, and storing the pixels for the media object
in the same database using the same ISAN.

Thus GDF does not provide an encoding mechanism directly in terms of bits
in the document, but an encoding mechanism is certainly provided. The GDF
viewer software, if it can present the pixels can also present the text.

We can rephrase the requirement to avoid reference to a content format as
follows:

"All non-text objects that are presented to the user must have a text
alternative that presents equivalent information, except for the situations
listed below."

Which is the non-text content provision for software. So the first content
provision is in fact logically redundant.

This will also be true for all of the proposed content provisions.


Sean Hayes
Incubation Lab
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,
Mobile: +44 7875 091385


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Hoffman,
Allen
Sent: 21 September 2007 16:03
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] intro for 8.1?

Chicken and egg:

(a) is format, b is deliverable and/or document.

So, if (format) can't store or represent, just as an example, text for
images, then document (b) that uses images won't be able to be compliant
for that requirement. so if a deliverable is represented as compliant,
but is in a underlying format that won't support the ability to comply
with a requirement, we know there is a problem somewhere.

The idea is to drive people to formats that can support more
accessibility over less, just as we do for other EIT. currently we
often get the push back that we can't comply because the format won't do
what you need, and "we have to use that format". This format
preselection is usually a false business need. Most of us don't have a
business need to use only one format. sometimes we do but the format
selection decision should not be made in a vacuum as it bears directly
on the accessibility of the end products so greatly.




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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andrew
Kirkpatrick
Sent: Friday, September 21, 2007 9:46 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] intro for 8.1?

Allen,
I'm sorry, but your message is just a little too cryptic for me to
follow. Can you fill in "a" and "b" with actual items?
Thanks,
AWK



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Hoffman, Allen
> Sent: Friday, September 21, 2007 8:01 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> I think we're talking chicken and egg kinds of things.
>
> A can't do B if A doesn't allow for B.
> if you don't need B, its not important--but knowing what A can and
> can't do is important. -- channeling some Sean Hayes here.
>
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Andrew Kirkpatrick
> Sent: Thursday, September 20, 2007 4:39 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> This is part of what I'm asking.
>
> Also a part of what I'm asking is due to differences in what products
> support. A product may not use all of the accessibility features in a

> format, and more specifically, a product may not need to use all of
> the support available in a format, depending on the use of the
> product.
> Imagine a format that complies with everything except the format
> doesn't allow for equivalents for images. If a government agency
> knows that the product doesn't create images in its output, even
> though the format doesn't support this, it doesn't matter for that
> product - what is important is the output of the product.
>
> AWK
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> > Tobias
> > Sent: Thursday, September 20, 2007 3:31 PM
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > I don't see why the entire format info would have to be in
> a VPAT if
> > it's a public, standard format used by the authoring tool in a
> > standard way. If the tool deviates from the format in any
> important
> > way that would have to be documented.
> >
> > Am I missing something?
> >
> > ***
> > Jim Tobias
> > Inclusive Technologies
> > +1.732.441.0831 v/tty
> > +1.908.907.2387 mobile
> > skype jimtobias
> >
> >
> > > -----Original Message-----
> > > From: Hoffman, Allen [mailto: = EMAIL ADDRESS REMOVED = ]
> > > Sent: Thursday, September 20, 2007 2:39 PM
> > > To: TEITAC Web/Software Subcommittee
> > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > >
> > > Point taken.
> > > Let me consider a bit and will post with a walk through
> of how this
> > > can work.
> > >
> > >
> > >
> > > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> > >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > > Andrew Kirkpatrick
> > > Sent: Thursday, September 20, 2007 2:36 PM
> > > To: TEITAC Web/Software Subcommittee
> > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > >
> > > This seems like a lot of additional overhead for a mere
> > sanity check.
> > > I'm envisioning a lot of confusion for procurement people
> when they
> > > receive a 16 page VPAT for a product that outputs in 5 different
> > > formats and needs to include information about the
> > capabilities of the
> > > format for each. Do you really expect that these people will
> > > cross-reference the product section 3 VPAT information
> against the
> > > various section 8 items for the format because it might
> reveal that
> > > the product VPAT author is declaring something that they
> shouldn't?
> > >
> > > AWK
> > >
> > >
> > > > -----Original Message-----
> > > > From: = EMAIL ADDRESS REMOVED =
> > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of
> > > > Hoffman, Allen
> > > > Sent: Thursday, September 20, 2007 1:07 PM
> > > > To: TEITAC Web/Software Subcommittee
> > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > >
> > > > Look at it as a sanity check.
> > > > If you state that, for example, you meet the language
> > > requirement in
> > > > 3, but select a format that doesn't include that capacity,
> > > something
> > > > is wrong.
> > > >
> > > >
> > > >
> > > > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> > > >
> > > > -----Original Message-----
> > > > From: = EMAIL ADDRESS REMOVED =
> > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of
> > > > Andrew Kirkpatrick
> > > > Sent: Thursday, September 20, 2007 1:04 PM
> > > > To: TEITAC Web/Software Subcommittee
> > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > >
> > > > Allen,
> > > >
> > > > You state "When determining the most accessible product
> > > from a set of
> > > > more than one, the format information is provided in can
> > > determine if
> > > > other requirements can be met or not" but just because a format
> > > > includes support for a particular standard it doesn't
> > mean that the
> > > > product that uses that format takes advantage of that support.
> > > >
> > > > How do you envision the support for the content formats
> > > being defined?
> > > > Does each content format have a VPAT? If so, who writes it?
> > > >
> > > > Part of my concern with the implementation of this section
> > > is that the
> > >
> > > > product is already reporting on how they support standards that
> > > > overlap with the content format items - I'm not sure
> that it will
> > > > actually help in procurement decisions since the product
> > > needs to meet
> > >
> > > > the section 3 standards, and the section 8 standards not
> > only don't
> > > > bring anything new to the picture but they are not necessarily
> > > > representative of the accessibility in the specific product.
> > > >
> > > > AWK
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: = EMAIL ADDRESS REMOVED =
> > > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> > Behalf Of
> > > > > Hoffman, Allen
> > > > > Sent: Thursday, September 20, 2007 11:43 AM
> > > > > To: TEITAC Web/Software Subcommittee
> > > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > > >
> > > > > All:
> > > > >
> > > > > Several people have raised questions related to how
> > > > provisions in 8.1
> > > > > relate to other sections. I think I'd like to propose an
> > > update to
> > > > > the draft for 09/14 to include some intro materials to
> > > > alleviate this
> > > > > concern, as it is obvious some connection is needed to
> > make this
> > > > > self-evident.
> > > > >
> > > > > So:
> > > > >
> > > > > Sections 3 and 6 above require that information
> > delivered must be
> > > > > presented meeting accessibility requirements. To
> > > accomplish this,
> > > > > information storage formats must allow for inclusion
> of certain
> > > > > accessibility related attributes and/or functionalities.
> > > > This section
> > > >
> > > > > describes the functional accessibility requirements for
> > > > such formats.
> > > > > When determining the most accessible product from a set of
> > > > more than
> > > > > one, the format information is provided in can
> > determine if other
> > > > > requirements can be met or not, and can be an important
> > > > factor in the
> > > > > final determination. Note:
> > > > > Formats which do not include some functionalities such as
> > > > the ability
> > > > > to represent synchronized media, would not be subject to that
> > > > > provision.
> > > > >
> > > > >
> > > > >

From: Hoffman, Allen
Date: Fri, Sep 21 2007 12:05 PM
Subject: Re: intro for 8.1?

I can tell you that when we look at deliverables, or projects in
development, which are delivering significant amounts of content, as
opposed to primarily user-interface, "what format" is a big question,
and often a big issue to deal with to achieve compliance. As we expand
our notion of what we cover to include these other content formats
beyond strictly HTML, addressing this underlying issue begs for a
yardstick for format selection. I would be happy if these provisions
were put in a section of agency responsibility, e.g. in the
information/documentation/support section. The connector between
delivered product and format selection does need to be made, since while
we can find situations where they are not fully dependent, the problems
are related, and usually they are related directly.




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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andi
Snow-Weaver
Sent: Friday, September 21, 2007 1:20 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] intro for 8.1?

So Sean, are you proposing that we don't need the content format
provisions at all? I think that is also Andrew's point.

Andi





Sean Hayes

<Sean.Hayes@micro

soft.com>
To
Sent by: TEITAC Web/Software Subcommittee

teitac-websoftwar
< = EMAIL ADDRESS REMOVED =
= EMAIL ADDRESS REMOVED = >

itac.org
cc



Subject
09/21/2007 10:55 Re: [teitac-websoftware] intro
for
AM 8.1?





Please respond to

TEITAC

Web/Software

Subcommittee

<teitac-websoftwa

= EMAIL ADDRESS REMOVED =

g>









"So, if (format) can't store or represent, just as an example, text for
images, then document (b) that uses images won't be able to be compliant
for that requirement ".

Is too narrow a view of the requirement.

"When a content format supports non-text objects, an encoding mechanism
shall be provided to associate non-text objects with textual
descriptions displayable by a user-agent."

There is a higher level here. What is the task trying to achieve?

The requirement to associate text with images is there so that an
individual that can't see the image can understand the content. The
requirement really is that the both the image and the text exist, and
the association between them is preserved so that when an arbitrary user
comes across the image, they also get the text.

It is not necessarily a requirement that a format encode both the image
and the text, or indeed the association.

For example GIF and HTML are both content formats. HTML does not encode
the pixel data, GIF does not encode the text. It is the combination of
the formats which provides the necessary information. The association is
provided by the src and alt attributes, which in this case happens to be
embedded in the HTML and the text is stored locally however this is not
the only configuration which would work.

We could envision different systems, which would also fulfil the purpose
of the task; for example a metadata database which can associate an
image with the text for that image. The text might be in another
resource entirely (e.g. a resource fork or a properties file). Or the
text might be in metadata in the image itself.

Let us posit the GregorianDocumentFormat (GDF) which 'supports' a
non-text media format by including a reference to it using its ISAN
number.

Authors associate text for the media object by indexing the text in a
data repository using the same ISAN, and storing the pixels for the
media object in the same database using the same ISAN.

Thus GDF does not provide an encoding mechanism directly in terms of
bits in the document, but an encoding mechanism is certainly provided.
The GDF viewer software, if it can present the pixels can also present
the text.

We can rephrase the requirement to avoid reference to a content format
as
follows:

"All non-text objects that are presented to the user must have a text
alternative that presents equivalent information, except for the
situations listed below."

Which is the non-text content provision for software. So the first
content provision is in fact logically redundant.

This will also be true for all of the proposed content provisions.


Sean Hayes
Incubation Lab
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,
Mobile: +44 7875 091385


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
Hoffman, Allen
Sent: 21 September 2007 16:03
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] intro for 8.1?

Chicken and egg:

(a) is format, b is deliverable and/or document.

So, if (format) can't store or represent, just as an example, text for
images, then document (b) that uses images won't be able to be compliant
for that requirement. so if a deliverable is represented as compliant,
but is in a underlying format that won't support the ability to comply
with a requirement, we know there is a problem somewhere.

The idea is to drive people to formats that can support more
accessibility over less, just as we do for other EIT. currently we
often get the push back that we can't comply because the format won't do
what you need, and "we have to use that format". This format
preselection is usually a false business need. Most of us don't have a
business need to use only one format. sometimes we do but the format
selection decision should not be made in a vacuum as it bears directly
on the accessibility of the end products so greatly.




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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andrew
Kirkpatrick
Sent: Friday, September 21, 2007 9:46 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] intro for 8.1?

Allen,
I'm sorry, but your message is just a little too cryptic for me to
follow. Can you fill in "a" and "b" with actual items?
Thanks,
AWK



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Hoffman, Allen
> Sent: Friday, September 21, 2007 8:01 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> I think we're talking chicken and egg kinds of things.
>
> A can't do B if A doesn't allow for B.
> if you don't need B, its not important--but knowing what A can and
> can't do is important. -- channeling some Sean Hayes here.
>
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Andrew Kirkpatrick
> Sent: Thursday, September 20, 2007 4:39 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> This is part of what I'm asking.
>
> Also a part of what I'm asking is due to differences in what products
> support. A product may not use all of the accessibility features in a

> format, and more specifically, a product may not need to use all of
> the support available in a format, depending on the use of the
> product.
> Imagine a format that complies with everything except the format
> doesn't allow for equivalents for images. If a government agency
> knows that the product doesn't create images in its output, even
> though the format doesn't support this, it doesn't matter for that
> product - what is important is the output of the product.
>
> AWK
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> > Tobias
> > Sent: Thursday, September 20, 2007 3:31 PM
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > I don't see why the entire format info would have to be in
> a VPAT if
> > it's a public, standard format used by the authoring tool in a
> > standard way. If the tool deviates from the format in any
> important
> > way that would have to be documented.
> >
> > Am I missing something?
> >
> > ***
> > Jim Tobias
> > Inclusive Technologies
> > +1.732.441.0831 v/tty
> > +1.908.907.2387 mobile
> > skype jimtobias
> >
> >
> > > -----Original Message-----
> > > From: Hoffman, Allen [mailto: = EMAIL ADDRESS REMOVED = ]
> > > Sent: Thursday, September 20, 2007 2:39 PM
> > > To: TEITAC Web/Software Subcommittee
> > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > >
> > > Point taken.
> > > Let me consider a bit and will post with a walk through
> of how this
> > > can work.
> > >
> > >
> > >
> > > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> > >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > > Andrew Kirkpatrick
> > > Sent: Thursday, September 20, 2007 2:36 PM
> > > To: TEITAC Web/Software Subcommittee
> > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > >
> > > This seems like a lot of additional overhead for a mere
> > sanity check.
> > > I'm envisioning a lot of confusion for procurement people
> when they
> > > receive a 16 page VPAT for a product that outputs in 5 different
> > > formats and needs to include information about the
> > capabilities of the
> > > format for each. Do you really expect that these people will
> > > cross-reference the product section 3 VPAT information
> against the
> > > various section 8 items for the format because it might
> reveal that
> > > the product VPAT author is declaring something that they
> shouldn't?
> > >
> > > AWK
> > >
> > >
> > > > -----Original Message-----
> > > > From: = EMAIL ADDRESS REMOVED =
> > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of
> > > > Hoffman, Allen
> > > > Sent: Thursday, September 20, 2007 1:07 PM
> > > > To: TEITAC Web/Software Subcommittee
> > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > >
> > > > Look at it as a sanity check.
> > > > If you state that, for example, you meet the language
> > > requirement in
> > > > 3, but select a format that doesn't include that capacity,
> > > something
> > > > is wrong.
> > > >
> > > >
> > > >
> > > > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> > > >
> > > > -----Original Message-----
> > > > From: = EMAIL ADDRESS REMOVED =
> > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of
> > > > Andrew Kirkpatrick
> > > > Sent: Thursday, September 20, 2007 1:04 PM
> > > > To: TEITAC Web/Software Subcommittee
> > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > >
> > > > Allen,
> > > >
> > > > You state "When determining the most accessible product
> > > from a set of
> > > > more than one, the format information is provided in can
> > > determine if
> > > > other requirements can be met or not" but just because a format
> > > > includes support for a particular standard it doesn't
> > mean that the
> > > > product that uses that format takes advantage of that support.
> > > >
> > > > How do you envision the support for the content formats
> > > being defined?
> > > > Does each content format have a VPAT? If so, who writes it?
> > > >
> > > > Part of my concern with the implementation of this section
> > > is that the
> > >
> > > > product is already reporting on how they support standards that
> > > > overlap with the content format items - I'm not sure
> that it will
> > > > actually help in procurement decisions since the product
> > > needs to meet
> > >
> > > > the section 3 standards, and the section 8 standards not
> > only don't
> > > > bring anything new to the picture but they are not necessarily
> > > > representative of the accessibility in the specific product.
> > > >
> > > > AWK
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: = EMAIL ADDRESS REMOVED =
> > > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> > Behalf Of
> > > > > Hoffman, Allen
> > > > > Sent: Thursday, September 20, 2007 11:43 AM
> > > > > To: TEITAC Web/Software Subcommittee
> > > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > > >
> > > > > All:
> > > > >
> > > > > Several people have raised questions related to how
> > > > provisions in 8.1
> > > > > relate to other sections. I think I'd like to propose an
> > > update to
> > > > > the draft for 09/14 to include some intro materials to
> > > > alleviate this
> > > > > concern, as it is obvious some connection is needed to
> > make this
> > > > > self-evident.
> > > > >
> > > > > So:
> > > > >
> > > > > Sections 3 and 6 above require that information
> > delivered must be
> > > > > presented meeting accessibility requirements. To
> > > accomplish this,
> > > > > information storage formats must allow for inclusion
> of certain
> > > > > accessibility related attributes and/or functionalities.
> > > > This section
> > > >
> > > > > describes the functional accessibility requirements for
> > > > such formats.
> > > > > When determining the most accessible product from a set of
> > > > more than
> > > > > one, the format information is provided in can
> > determine if other
> > > > > requirements can be met or not, and can be an important
> > > > factor in the
> > > > > final determination. Note:
> > > > > Formats which do not include some functionalities such as
> > > > the ability
> > > > > to represent synchronized media, would not be subject to that
> > > > > provision.
> > > > >
> > > > >
> > > > >

From: Sean Hayes
Date: Sat, Sep 22 2007 1:55 AM
Subject: Re: intro for 8.1?

Yes. I believe they ought to be covered by the presentational and operational requirements of software, which induces the necessary requirement on the inputs to that software (as well as possibly on the operation of the software), without constraining the technical realisation of those requirements.

Sean Hayes
Incubation Lab
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,
Mobile: +44 7875 091385


-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andi Snow-Weaver
Sent: 21 September 2007 18:20
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] intro for 8.1?

So Sean, are you proposing that we don't need the content format provisions
at all? I think that is also Andrew's point.

Andi




Sean Hayes
<Sean.Hayes@micro
soft.com> To
Sent by: TEITAC Web/Software Subcommittee
teitac-websoftwar < = EMAIL ADDRESS REMOVED =
= EMAIL ADDRESS REMOVED = >
itac.org cc

Subject
09/21/2007 10:55 Re: [teitac-websoftware] intro for
AM 8.1?


Please respond to
TEITAC
Web/Software
Subcommittee
<teitac-websoftwa
= EMAIL ADDRESS REMOVED =
g>






"So, if (format) can't store or represent, just as an example, text for
images, then document (b) that uses images won't be able to be compliant
for that requirement ".

Is too narrow a view of the requirement.

"When a content format supports non-text objects, an encoding mechanism
shall be provided to associate non-text objects with textual descriptions
displayable by a user-agent."

There is a higher level here. What is the task trying to achieve?

The requirement to associate text with images is there so that an
individual that can't see the image can understand the content. The
requirement really is that the both the image and the text exist, and the
association between them is preserved so that when an arbitrary user comes
across the image, they also get the text.

It is not necessarily a requirement that a format encode both the image and
the text, or indeed the association.

For example GIF and HTML are both content formats. HTML does not encode the
pixel data, GIF does not encode the text. It is the combination of the
formats which provides the necessary information. The association is
provided by the src and alt attributes, which in this case happens to be
embedded in the HTML and the text is stored locally however this is not the
only configuration which would work.

We could envision different systems, which would also fulfil the purpose of
the task; for example a metadata database which can associate an image with
the text for that image. The text might be in another resource entirely
(e.g. a resource fork or a properties file). Or the text might be in
metadata in the image itself.

Let us posit the GregorianDocumentFormat (GDF) which 'supports' a non-text
media format by including a reference to it using its ISAN number.

Authors associate text for the media object by indexing the text in a data
repository using the same ISAN, and storing the pixels for the media object
in the same database using the same ISAN.

Thus GDF does not provide an encoding mechanism directly in terms of bits
in the document, but an encoding mechanism is certainly provided. The GDF
viewer software, if it can present the pixels can also present the text.

We can rephrase the requirement to avoid reference to a content format as
follows:

"All non-text objects that are presented to the user must have a text
alternative that presents equivalent information, except for the situations
listed below."

Which is the non-text content provision for software. So the first content
provision is in fact logically redundant.

This will also be true for all of the proposed content provisions.


Sean Hayes
Incubation Lab
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,
Mobile: +44 7875 091385


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Hoffman,
Allen
Sent: 21 September 2007 16:03
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] intro for 8.1?

Chicken and egg:

(a) is format, b is deliverable and/or document.

So, if (format) can't store or represent, just as an example, text for
images, then document (b) that uses images won't be able to be compliant
for that requirement. so if a deliverable is represented as compliant,
but is in a underlying format that won't support the ability to comply
with a requirement, we know there is a problem somewhere.

The idea is to drive people to formats that can support more
accessibility over less, just as we do for other EIT. currently we
often get the push back that we can't comply because the format won't do
what you need, and "we have to use that format". This format
preselection is usually a false business need. Most of us don't have a
business need to use only one format. sometimes we do but the format
selection decision should not be made in a vacuum as it bears directly
on the accessibility of the end products so greatly.




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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andrew
Kirkpatrick
Sent: Friday, September 21, 2007 9:46 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] intro for 8.1?

Allen,
I'm sorry, but your message is just a little too cryptic for me to
follow. Can you fill in "a" and "b" with actual items?
Thanks,
AWK



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Hoffman, Allen
> Sent: Friday, September 21, 2007 8:01 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> I think we're talking chicken and egg kinds of things.
>
> A can't do B if A doesn't allow for B.
> if you don't need B, its not important--but knowing what A can and
> can't do is important. -- channeling some Sean Hayes here.
>
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Andrew Kirkpatrick
> Sent: Thursday, September 20, 2007 4:39 PM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> This is part of what I'm asking.
>
> Also a part of what I'm asking is due to differences in what products
> support. A product may not use all of the accessibility features in a

> format, and more specifically, a product may not need to use all of
> the support available in a format, depending on the use of the
> product.
> Imagine a format that complies with everything except the format
> doesn't allow for equivalents for images. If a government agency
> knows that the product doesn't create images in its output, even
> though the format doesn't support this, it doesn't matter for that
> product - what is important is the output of the product.
>
> AWK
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> > Tobias
> > Sent: Thursday, September 20, 2007 3:31 PM
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > I don't see why the entire format info would have to be in
> a VPAT if
> > it's a public, standard format used by the authoring tool in a
> > standard way. If the tool deviates from the format in any
> important
> > way that would have to be documented.
> >
> > Am I missing something?
> >
> > ***
> > Jim Tobias
> > Inclusive Technologies
> > +1.732.441.0831 v/tty
> > +1.908.907.2387 mobile
> > skype jimtobias
> >
> >
> > > -----Original Message-----
> > > From: Hoffman, Allen [mailto: = EMAIL ADDRESS REMOVED = ]
> > > Sent: Thursday, September 20, 2007 2:39 PM
> > > To: TEITAC Web/Software Subcommittee
> > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > >
> > > Point taken.
> > > Let me consider a bit and will post with a walk through
> of how this
> > > can work.
> > >
> > >
> > >
> > > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> > >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > > Andrew Kirkpatrick
> > > Sent: Thursday, September 20, 2007 2:36 PM
> > > To: TEITAC Web/Software Subcommittee
> > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > >
> > > This seems like a lot of additional overhead for a mere
> > sanity check.
> > > I'm envisioning a lot of confusion for procurement people
> when they
> > > receive a 16 page VPAT for a product that outputs in 5 different
> > > formats and needs to include information about the
> > capabilities of the
> > > format for each. Do you really expect that these people will
> > > cross-reference the product section 3 VPAT information
> against the
> > > various section 8 items for the format because it might
> reveal that
> > > the product VPAT author is declaring something that they
> shouldn't?
> > >
> > > AWK
> > >
> > >
> > > > -----Original Message-----
> > > > From: = EMAIL ADDRESS REMOVED =
> > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of
> > > > Hoffman, Allen
> > > > Sent: Thursday, September 20, 2007 1:07 PM
> > > > To: TEITAC Web/Software Subcommittee
> > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > >
> > > > Look at it as a sanity check.
> > > > If you state that, for example, you meet the language
> > > requirement in
> > > > 3, but select a format that doesn't include that capacity,
> > > something
> > > > is wrong.
> > > >
> > > >
> > > >
> > > > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> > > >
> > > > -----Original Message-----
> > > > From: = EMAIL ADDRESS REMOVED =
> > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of
> > > > Andrew Kirkpatrick
> > > > Sent: Thursday, September 20, 2007 1:04 PM
> > > > To: TEITAC Web/Software Subcommittee
> > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > >
> > > > Allen,
> > > >
> > > > You state "When determining the most accessible product
> > > from a set of
> > > > more than one, the format information is provided in can
> > > determine if
> > > > other requirements can be met or not" but just because a format
> > > > includes support for a particular standard it doesn't
> > mean that the
> > > > product that uses that format takes advantage of that support.
> > > >
> > > > How do you envision the support for the content formats
> > > being defined?
> > > > Does each content format have a VPAT? If so, who writes it?
> > > >
> > > > Part of my concern with the implementation of this section
> > > is that the
> > >
> > > > product is already reporting on how they support standards that
> > > > overlap with the content format items - I'm not sure
> that it will
> > > > actually help in procurement decisions since the product
> > > needs to meet
> > >
> > > > the section 3 standards, and the section 8 standards not
> > only don't
> > > > bring anything new to the picture but they are not necessarily
> > > > representative of the accessibility in the specific product.
> > > >
> > > > AWK
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: = EMAIL ADDRESS REMOVED =
> > > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> > Behalf Of
> > > > > Hoffman, Allen
> > > > > Sent: Thursday, September 20, 2007 11:43 AM
> > > > > To: TEITAC Web/Software Subcommittee
> > > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > > >
> > > > > All:
> > > > >
> > > > > Several people have raised questions related to how
> > > > provisions in 8.1
> > > > > relate to other sections. I think I'd like to propose an
> > > update to
> > > > > the draft for 09/14 to include some intro materials to
> > > > alleviate this
> > > > > concern, as it is obvious some connection is needed to
> > make this
> > > > > self-evident.
> > > > >
> > > > > So:
> > > > >
> > > > > Sections 3 and 6 above require that information
> > delivered must be
> > > > > presented meeting accessibility requirements. To
> > > accomplish this,
> > > > > information storage formats must allow for inclusion
> of certain
> > > > > accessibility related attributes and/or functionalities.
> > > > This section
> > > >
> > > > > describes the functional accessibility requirements for
> > > > such formats.
> > > > > When determining the most accessible product from a set of
> > > > more than
> > > > > one, the format information is provided in can
> > determine if other
> > > > > requirements can be met or not, and can be an important
> > > > factor in the
> > > > > final determination. Note:
> > > > > Formats which do not include some functionalities such as
> > > > the ability
> > > > > to represent synchronized media, would not be subject to that
> > > > > provision.
> > > > >
> > > > >
> > > > >

From: Jim Tobias
Date: Sat, Sep 22 2007 5:35 AM
Subject: Re: intro for 8.1?

I disagree. Formats that cannot carry accessibility information should be
excluded from procurement so that they do not infect "use". 508 has a hard
time influencing anything other than procurement, and this is one of the
best opportunities to do so.

Formats are an important part of the accessibility value chain, and all
elements of that chain should be subjected to evaluation. That was the
original thinking behind addressing them, and it still seems correct to me.

***
Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias


> -----Original Message-----
> From: Sean Hayes [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Saturday, September 22, 2007 3:50 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Yes. I believe they ought to be covered by the presentational
> and operational requirements of software, which induces the
> necessary requirement on the inputs to that software (as well
> as possibly on the operation of the software), without
> constraining the technical realisation of those requirements.
>
> Sean Hayes
> Incubation Lab
> Accessibility Business Unit
> Microsoft
>
> Office: +44 118 909 5867,
> Mobile: +44 7875 091385
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Andi Snow-Weaver
> Sent: 21 September 2007 18:20
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> So Sean, are you proposing that we don't need the content
> format provisions at all? I think that is also Andrew's point.
>
> Andi
>
>
>
>
> Sean Hayes
> <Sean.Hayes@micro
> soft.com>
> To
> Sent by: TEITAC Web/Software
> Subcommittee
> teitac-websoftwar
> < = EMAIL ADDRESS REMOVED =
> = EMAIL ADDRESS REMOVED = >
> itac.org
> cc
>
>
> Subject
> 09/21/2007 10:55 Re:
> [teitac-websoftware] intro for
> AM 8.1?
>
>
> Please respond to
> TEITAC
> Web/Software
> Subcommittee
> <teitac-websoftwa
> = EMAIL ADDRESS REMOVED =
> g>
>
>
>
>
>
>
> "So, if (format) can't store or represent, just as an
> example, text for images, then document (b) that uses images
> won't be able to be compliant for that requirement ".
>
> Is too narrow a view of the requirement.
>
> "When a content format supports non-text objects, an encoding
> mechanism shall be provided to associate non-text objects
> with textual descriptions displayable by a user-agent."
>
> There is a higher level here. What is the task trying to achieve?
>
> The requirement to associate text with images is there so
> that an individual that can't see the image can understand
> the content. The requirement really is that the both the
> image and the text exist, and the association between them is
> preserved so that when an arbitrary user comes across the
> image, they also get the text.
>
> It is not necessarily a requirement that a format encode both
> the image and the text, or indeed the association.
>
> For example GIF and HTML are both content formats. HTML does
> not encode the pixel data, GIF does not encode the text. It
> is the combination of the formats which provides the
> necessary information. The association is provided by the src
> and alt attributes, which in this case happens to be embedded
> in the HTML and the text is stored locally however this is
> not the only configuration which would work.
>
> We could envision different systems, which would also fulfil
> the purpose of the task; for example a metadata database
> which can associate an image with the text for that image.
> The text might be in another resource entirely (e.g. a
> resource fork or a properties file). Or the text might be in
> metadata in the image itself.
>
> Let us posit the GregorianDocumentFormat (GDF) which
> 'supports' a non-text media format by including a reference
> to it using its ISAN number.
>
> Authors associate text for the media object by indexing the
> text in a data repository using the same ISAN, and storing
> the pixels for the media object in the same database using
> the same ISAN.
>
> Thus GDF does not provide an encoding mechanism directly in
> terms of bits in the document, but an encoding mechanism is
> certainly provided. The GDF viewer software, if it can
> present the pixels can also present the text.
>
> We can rephrase the requirement to avoid reference to a
> content format as
> follows:
>
> "All non-text objects that are presented to the user must
> have a text alternative that presents equivalent information,
> except for the situations listed below."
>
> Which is the non-text content provision for software. So the
> first content provision is in fact logically redundant.
>
> This will also be true for all of the proposed content provisions.
>
>
> Sean Hayes
> Incubation Lab
> Accessibility Business Unit
> Microsoft
>
> Office: +44 118 909 5867,
> Mobile: +44 7875 091385
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Hoffman, Allen
> Sent: 21 September 2007 16:03
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Chicken and egg:
>
> (a) is format, b is deliverable and/or document.
>
> So, if (format) can't store or represent, just as an example,
> text for images, then document (b) that uses images won't be
> able to be compliant for that requirement. so if a
> deliverable is represented as compliant, but is in a
> underlying format that won't support the ability to comply
> with a requirement, we know there is a problem somewhere.
>
> The idea is to drive people to formats that can support more
> accessibility over less, just as we do for other EIT.
> currently we often get the push back that we can't comply
> because the format won't do what you need, and "we have to
> use that format". This format preselection is usually a
> false business need. Most of us don't have a business need
> to use only one format. sometimes we do but the format
> selection decision should not be made in a vacuum as it bears
> directly on the accessibility of the end products so greatly.
>
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Andrew Kirkpatrick
> Sent: Friday, September 21, 2007 9:46 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Allen,
> I'm sorry, but your message is just a little too cryptic for
> me to follow. Can you fill in "a" and "b" with actual items?
> Thanks,
> AWK
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > Hoffman, Allen
> > Sent: Friday, September 21, 2007 8:01 AM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > I think we're talking chicken and egg kinds of things.
> >
> > A can't do B if A doesn't allow for B.
> > if you don't need B, its not important--but knowing what A can and
> > can't do is important. -- channeling some Sean Hayes here.
> >
> >
> >
> >
> > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > Andrew Kirkpatrick
> > Sent: Thursday, September 20, 2007 4:39 PM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > This is part of what I'm asking.
> >
> > Also a part of what I'm asking is due to differences in
> what products
> > support. A product may not use all of the accessibility
> features in a
>
> > format, and more specifically, a product may not need to use all of
> > the support available in a format, depending on the use of the
> > product.
> > Imagine a format that complies with everything except the format
> > doesn't allow for equivalents for images. If a government agency
> > knows that the product doesn't create images in its output, even
> > though the format doesn't support this, it doesn't matter for that
> > product - what is important is the output of the product.
> >
> > AWK
> >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> > Behalf Of Jim
> > > Tobias
> > > Sent: Thursday, September 20, 2007 3:31 PM
> > > To: 'TEITAC Web/Software Subcommittee'
> > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > >
> > > I don't see why the entire format info would have to be in
> > a VPAT if
> > > it's a public, standard format used by the authoring tool in a
> > > standard way. If the tool deviates from the format in any
> > important
> > > way that would have to be documented.
> > >
> > > Am I missing something?
> > >
> > > ***
> > > Jim Tobias
> > > Inclusive Technologies
> > > +1.732.441.0831 v/tty
> > > +1.908.907.2387 mobile
> > > skype jimtobias
> > >
> > >
> > > > -----Original Message-----
> > > > From: Hoffman, Allen [mailto: = EMAIL ADDRESS REMOVED = ]
> > > > Sent: Thursday, September 20, 2007 2:39 PM
> > > > To: TEITAC Web/Software Subcommittee
> > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > >
> > > > Point taken.
> > > > Let me consider a bit and will post with a walk through
> > of how this
> > > > can work.
> > > >
> > > >
> > > >
> > > > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> > > >
> > > > -----Original Message-----
> > > > From: = EMAIL ADDRESS REMOVED =
> > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of
> > > > Andrew Kirkpatrick
> > > > Sent: Thursday, September 20, 2007 2:36 PM
> > > > To: TEITAC Web/Software Subcommittee
> > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > >
> > > > This seems like a lot of additional overhead for a mere
> > > sanity check.
> > > > I'm envisioning a lot of confusion for procurement people
> > when they
> > > > receive a 16 page VPAT for a product that outputs in 5
> different
> > > > formats and needs to include information about the
> > > capabilities of the
> > > > format for each. Do you really expect that these people will
> > > > cross-reference the product section 3 VPAT information
> > against the
> > > > various section 8 items for the format because it might
> > reveal that
> > > > the product VPAT author is declaring something that they
> > shouldn't?
> > > >
> > > > AWK
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: = EMAIL ADDRESS REMOVED =
> > > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> > Behalf Of
> > > > > Hoffman, Allen
> > > > > Sent: Thursday, September 20, 2007 1:07 PM
> > > > > To: TEITAC Web/Software Subcommittee
> > > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > > >
> > > > > Look at it as a sanity check.
> > > > > If you state that, for example, you meet the language
> > > > requirement in
> > > > > 3, but select a format that doesn't include that capacity,
> > > > something
> > > > > is wrong.
> > > > >
> > > > >
> > > > >
> > > > > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> > > > >
> > > > > -----Original Message-----
> > > > > From: = EMAIL ADDRESS REMOVED =
> > > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> > Behalf Of
> > > > > Andrew Kirkpatrick
> > > > > Sent: Thursday, September 20, 2007 1:04 PM
> > > > > To: TEITAC Web/Software Subcommittee
> > > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > > >
> > > > > Allen,
> > > > >
> > > > > You state "When determining the most accessible product
> > > > from a set of
> > > > > more than one, the format information is provided in can
> > > > determine if
> > > > > other requirements can be met or not" but just
> because a format
> > > > > includes support for a particular standard it doesn't
> > > mean that the
> > > > > product that uses that format takes advantage of that support.
> > > > >
> > > > > How do you envision the support for the content formats
> > > > being defined?
> > > > > Does each content format have a VPAT? If so, who writes it?
> > > > >
> > > > > Part of my concern with the implementation of this section
> > > > is that the
> > > >
> > > > > product is already reporting on how they support
> standards that
> > > > > overlap with the content format items - I'm not sure
> > that it will
> > > > > actually help in procurement decisions since the product
> > > > needs to meet
> > > >
> > > > > the section 3 standards, and the section 8 standards not
> > > only don't
> > > > > bring anything new to the picture but they are not
> necessarily
> > > > > representative of the accessibility in the specific product.
> > > > >
> > > > > AWK
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: = EMAIL ADDRESS REMOVED =
> > > > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> > > Behalf Of
> > > > > > Hoffman, Allen
> > > > > > Sent: Thursday, September 20, 2007 11:43 AM
> > > > > > To: TEITAC Web/Software Subcommittee
> > > > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > > > >
> > > > > > All:
> > > > > >
> > > > > > Several people have raised questions related to how
> > > > > provisions in 8.1
> > > > > > relate to other sections. I think I'd like to propose an
> > > > update to
> > > > > > the draft for 09/14 to include some intro materials to
> > > > > alleviate this
> > > > > > concern, as it is obvious some connection is needed to
> > > make this
> > > > > > self-evident.
> > > > > >
> > > > > > So:
> > > > > >
> > > > > > Sections 3 and 6 above require that information
> > > delivered must be
> > > > > > presented meeting accessibility requirements. To
> > > > accomplish this,
> > > > > > information storage formats must allow for inclusion
> > of certain
> > > > > > accessibility related attributes and/or functionalities.
> > > > > This section
> > > > >
> > > > > > describes the functional accessibility requirements for
> > > > > such formats.
> > > > > > When determining the most accessible product from a set of
> > > > > more than
> > > > > > one, the format information is provided in can
> > > determine if other
> > > > > > requirements can be met or not, and can be an important
> > > > > factor in the
> > > > > > final determination. Note:
> > > > > > Formats which do not include some functionalities such as
> > > > > the ability
> > > > > > to represent synchronized media, would not be
> subject to that
> > > > > > provision.
> > > > > >
> > > > > >
> > > > > >

From: Sean Hayes
Date: Sat, Sep 22 2007 5:40 AM
Subject: Re: intro for 8.1?

That's OK, formats that don't carry accessibility information are excluded from procurement by the software rules, because the software cannot display the information if it's not present.

Sean Hayes
Incubation Lab
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,
Mobile: +44 7875 091385


-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim Tobias
Sent: 22 September 2007 12:33
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] intro for 8.1?

I disagree. Formats that cannot carry accessibility information should be
excluded from procurement so that they do not infect "use". 508 has a hard
time influencing anything other than procurement, and this is one of the
best opportunities to do so.

Formats are an important part of the accessibility value chain, and all
elements of that chain should be subjected to evaluation. That was the
original thinking behind addressing them, and it still seems correct to me.

***
Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias


> -----Original Message-----
> From: Sean Hayes [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Saturday, September 22, 2007 3:50 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Yes. I believe they ought to be covered by the presentational
> and operational requirements of software, which induces the
> necessary requirement on the inputs to that software (as well
> as possibly on the operation of the software), without
> constraining the technical realisation of those requirements.
>
> Sean Hayes
> Incubation Lab
> Accessibility Business Unit
> Microsoft
>
> Office: +44 118 909 5867,
> Mobile: +44 7875 091385
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Andi Snow-Weaver
> Sent: 21 September 2007 18:20
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> So Sean, are you proposing that we don't need the content
> format provisions at all? I think that is also Andrew's point.
>
> Andi
>
>
>
>
> Sean Hayes
> <Sean.Hayes@micro
> soft.com>
> To
> Sent by: TEITAC Web/Software
> Subcommittee
> teitac-websoftwar
> < = EMAIL ADDRESS REMOVED =
> = EMAIL ADDRESS REMOVED = >
> itac.org
> cc
>
>
> Subject
> 09/21/2007 10:55 Re:
> [teitac-websoftware] intro for
> AM 8.1?
>
>
> Please respond to
> TEITAC
> Web/Software
> Subcommittee
> <teitac-websoftwa
> = EMAIL ADDRESS REMOVED =
> g>
>
>
>
>
>
>
> "So, if (format) can't store or represent, just as an
> example, text for images, then document (b) that uses images
> won't be able to be compliant for that requirement ".
>
> Is too narrow a view of the requirement.
>
> "When a content format supports non-text objects, an encoding
> mechanism shall be provided to associate non-text objects
> with textual descriptions displayable by a user-agent."
>
> There is a higher level here. What is the task trying to achieve?
>
> The requirement to associate text with images is there so
> that an individual that can't see the image can understand
> the content. The requirement really is that the both the
> image and the text exist, and the association between them is
> preserved so that when an arbitrary user comes across the
> image, they also get the text.
>
> It is not necessarily a requirement that a format encode both
> the image and the text, or indeed the association.
>
> For example GIF and HTML are both content formats. HTML does
> not encode the pixel data, GIF does not encode the text. It
> is the combination of the formats which provides the
> necessary information. The association is provided by the src
> and alt attributes, which in this case happens to be embedded
> in the HTML and the text is stored locally however this is
> not the only configuration which would work.
>
> We could envision different systems, which would also fulfil
> the purpose of the task; for example a metadata database
> which can associate an image with the text for that image.
> The text might be in another resource entirely (e.g. a
> resource fork or a properties file). Or the text might be in
> metadata in the image itself.
>
> Let us posit the GregorianDocumentFormat (GDF) which
> 'supports' a non-text media format by including a reference
> to it using its ISAN number.
>
> Authors associate text for the media object by indexing the
> text in a data repository using the same ISAN, and storing
> the pixels for the media object in the same database using
> the same ISAN.
>
> Thus GDF does not provide an encoding mechanism directly in
> terms of bits in the document, but an encoding mechanism is
> certainly provided. The GDF viewer software, if it can
> present the pixels can also present the text.
>
> We can rephrase the requirement to avoid reference to a
> content format as
> follows:
>
> "All non-text objects that are presented to the user must
> have a text alternative that presents equivalent information,
> except for the situations listed below."
>
> Which is the non-text content provision for software. So the
> first content provision is in fact logically redundant.
>
> This will also be true for all of the proposed content provisions.
>
>
> Sean Hayes
> Incubation Lab
> Accessibility Business Unit
> Microsoft
>
> Office: +44 118 909 5867,
> Mobile: +44 7875 091385
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Hoffman, Allen
> Sent: 21 September 2007 16:03
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Chicken and egg:
>
> (a) is format, b is deliverable and/or document.
>
> So, if (format) can't store or represent, just as an example,
> text for images, then document (b) that uses images won't be
> able to be compliant for that requirement. so if a
> deliverable is represented as compliant, but is in a
> underlying format that won't support the ability to comply
> with a requirement, we know there is a problem somewhere.
>
> The idea is to drive people to formats that can support more
> accessibility over less, just as we do for other EIT.
> currently we often get the push back that we can't comply
> because the format won't do what you need, and "we have to
> use that format". This format preselection is usually a
> false business need. Most of us don't have a business need
> to use only one format. sometimes we do but the format
> selection decision should not be made in a vacuum as it bears
> directly on the accessibility of the end products so greatly.
>
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Andrew Kirkpatrick
> Sent: Friday, September 21, 2007 9:46 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Allen,
> I'm sorry, but your message is just a little too cryptic for
> me to follow. Can you fill in "a" and "b" with actual items?
> Thanks,
> AWK
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > Hoffman, Allen
> > Sent: Friday, September 21, 2007 8:01 AM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > I think we're talking chicken and egg kinds of things.
> >
> > A can't do B if A doesn't allow for B.
> > if you don't need B, its not important--but knowing what A can and
> > can't do is important. -- channeling some Sean Hayes here.
> >
> >
> >
> >
> > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > Andrew Kirkpatrick
> > Sent: Thursday, September 20, 2007 4:39 PM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > This is part of what I'm asking.
> >
> > Also a part of what I'm asking is due to differences in
> what products
> > support. A product may not use all of the accessibility
> features in a
>
> > format, and more specifically, a product may not need to use all of
> > the support available in a format, depending on the use of the
> > product.
> > Imagine a format that complies with everything except the format
> > doesn't allow for equivalents for images. If a government agency
> > knows that the product doesn't create images in its output, even
> > though the format doesn't support this, it doesn't matter for that
> > product - what is important is the output of the product.
> >
> > AWK
> >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> > Behalf Of Jim
> > > Tobias
> > > Sent: Thursday, September 20, 2007 3:31 PM
> > > To: 'TEITAC Web/Software Subcommittee'
> > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > >
> > > I don't see why the entire format info would have to be in
> > a VPAT if
> > > it's a public, standard format used by the authoring tool in a
> > > standard way. If the tool deviates from the format in any
> > important
> > > way that would have to be documented.
> > >
> > > Am I missing something?
> > >
> > > ***
> > > Jim Tobias
> > > Inclusive Technologies
> > > +1.732.441.0831 v/tty
> > > +1.908.907.2387 mobile
> > > skype jimtobias
> > >
> > >
> > > > -----Original Message-----
> > > > From: Hoffman, Allen [mailto: = EMAIL ADDRESS REMOVED = ]
> > > > Sent: Thursday, September 20, 2007 2:39 PM
> > > > To: TEITAC Web/Software Subcommittee
> > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > >
> > > > Point taken.
> > > > Let me consider a bit and will post with a walk through
> > of how this
> > > > can work.
> > > >
> > > >
> > > >
> > > > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> > > >
> > > > -----Original Message-----
> > > > From: = EMAIL ADDRESS REMOVED =
> > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of
> > > > Andrew Kirkpatrick
> > > > Sent: Thursday, September 20, 2007 2:36 PM
> > > > To: TEITAC Web/Software Subcommittee
> > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > >
> > > > This seems like a lot of additional overhead for a mere
> > > sanity check.
> > > > I'm envisioning a lot of confusion for procurement people
> > when they
> > > > receive a 16 page VPAT for a product that outputs in 5
> different
> > > > formats and needs to include information about the
> > > capabilities of the
> > > > format for each. Do you really expect that these people will
> > > > cross-reference the product section 3 VPAT information
> > against the
> > > > various section 8 items for the format because it might
> > reveal that
> > > > the product VPAT author is declaring something that they
> > shouldn't?
> > > >
> > > > AWK
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: = EMAIL ADDRESS REMOVED =
> > > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> > Behalf Of
> > > > > Hoffman, Allen
> > > > > Sent: Thursday, September 20, 2007 1:07 PM
> > > > > To: TEITAC Web/Software Subcommittee
> > > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > > >
> > > > > Look at it as a sanity check.
> > > > > If you state that, for example, you meet the language
> > > > requirement in
> > > > > 3, but select a format that doesn't include that capacity,
> > > > something
> > > > > is wrong.
> > > > >
> > > > >
> > > > >
> > > > > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> > > > >
> > > > > -----Original Message-----
> > > > > From: = EMAIL ADDRESS REMOVED =
> > > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> > Behalf Of
> > > > > Andrew Kirkpatrick
> > > > > Sent: Thursday, September 20, 2007 1:04 PM
> > > > > To: TEITAC Web/Software Subcommittee
> > > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > > >
> > > > > Allen,
> > > > >
> > > > > You state "When determining the most accessible product
> > > > from a set of
> > > > > more than one, the format information is provided in can
> > > > determine if
> > > > > other requirements can be met or not" but just
> because a format
> > > > > includes support for a particular standard it doesn't
> > > mean that the
> > > > > product that uses that format takes advantage of that support.
> > > > >
> > > > > How do you envision the support for the content formats
> > > > being defined?
> > > > > Does each content format have a VPAT? If so, who writes it?
> > > > >
> > > > > Part of my concern with the implementation of this section
> > > > is that the
> > > >
> > > > > product is already reporting on how they support
> standards that
> > > > > overlap with the content format items - I'm not sure
> > that it will
> > > > > actually help in procurement decisions since the product
> > > > needs to meet
> > > >
> > > > > the section 3 standards, and the section 8 standards not
> > > only don't
> > > > > bring anything new to the picture but they are not
> necessarily
> > > > > representative of the accessibility in the specific product.
> > > > >
> > > > > AWK
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: = EMAIL ADDRESS REMOVED =
> > > > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> > > Behalf Of
> > > > > > Hoffman, Allen
> > > > > > Sent: Thursday, September 20, 2007 11:43 AM
> > > > > > To: TEITAC Web/Software Subcommittee
> > > > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > > > >
> > > > > > All:
> > > > > >
> > > > > > Several people have raised questions related to how
> > > > > provisions in 8.1
> > > > > > relate to other sections. I think I'd like to propose an
> > > > update to
> > > > > > the draft for 09/14 to include some intro materials to
> > > > > alleviate this
> > > > > > concern, as it is obvious some connection is needed to
> > > make this
> > > > > > self-evident.
> > > > > >
> > > > > > So:
> > > > > >
> > > > > > Sections 3 and 6 above require that information
> > > delivered must be
> > > > > > presented meeting accessibility requirements. To
> > > > accomplish this,
> > > > > > information storage formats must allow for inclusion
> > of certain
> > > > > > accessibility related attributes and/or functionalities.
> > > > > This section
> > > > >
> > > > > > describes the functional accessibility requirements for
> > > > > such formats.
> > > > > > When determining the most accessible product from a set of
> > > > > more than
> > > > > > one, the format information is provided in can
> > > determine if other
> > > > > > requirements can be met or not, and can be an important
> > > > > factor in the
> > > > > > final determination. Note:
> > > > > > Formats which do not include some functionalities such as
> > > > > the ability
> > > > > > to represent synchronized media, would not be
> subject to that
> > > > > > provision.
> > > > > >
> > > > > >
> > > > > >

From: Jim Tobias
Date: Sat, Sep 22 2007 5:45 AM
Subject: Re: intro for 8.1?

Sorry -- can you point to the specific provision(s) that would have the
effect you claim? I'm not seeing it.

***
Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias


> -----Original Message-----
> From: Sean Hayes [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Saturday, September 22, 2007 7:37 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> That's OK, formats that don't carry accessibility information
> are excluded from procurement by the software rules, because
> the software cannot display the information if it's not present.
>
> Sean Hayes
> Incubation Lab
> Accessibility Business Unit
> Microsoft
>
> Office: +44 118 909 5867,
> Mobile: +44 7875 091385
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Jim Tobias
> Sent: 22 September 2007 12:33
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> I disagree. Formats that cannot carry accessibility
> information should be excluded from procurement so that they
> do not infect "use". 508 has a hard time influencing
> anything other than procurement, and this is one of the best
> opportunities to do so.
>
> Formats are an important part of the accessibility value
> chain, and all elements of that chain should be subjected to
> evaluation. That was the original thinking behind addressing
> them, and it still seems correct to me.
>
> ***
> Jim Tobias
> Inclusive Technologies
> +1.732.441.0831 v/tty
> +1.908.907.2387 mobile
> skype jimtobias
>
>
> > -----Original Message-----
> > From: Sean Hayes [mailto: = EMAIL ADDRESS REMOVED = ]
> > Sent: Saturday, September 22, 2007 3:50 AM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > Yes. I believe they ought to be covered by the presentational and
> > operational requirements of software, which induces the necessary
> > requirement on the inputs to that software (as well as
> possibly on the
> > operation of the software), without constraining the technical
> > realisation of those requirements.
> >
> > Sean Hayes
> > Incubation Lab
> > Accessibility Business Unit
> > Microsoft
> >
> > Office: +44 118 909 5867,
> > Mobile: +44 7875 091385
> >
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Andi
> > Snow-Weaver
> > Sent: 21 September 2007 18:20
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > So Sean, are you proposing that we don't need the content format
> > provisions at all? I think that is also Andrew's point.
> >
> > Andi
> >
> >
> >
> >
> > Sean Hayes
> > <Sean.Hayes@micro
> > soft.com>
> > To
> > Sent by: TEITAC Web/Software
> > Subcommittee
> > teitac-websoftwar
> > < = EMAIL ADDRESS REMOVED =
> > = EMAIL ADDRESS REMOVED = >
> > itac.org
> > cc
> >
> >
> > Subject
> > 09/21/2007 10:55 Re:
> > [teitac-websoftware] intro for
> > AM 8.1?
> >
> >
> > Please respond to
> > TEITAC
> > Web/Software
> > Subcommittee
> > <teitac-websoftwa
> > = EMAIL ADDRESS REMOVED =
> > g>
> >
> >
> >
> >
> >
> >
> > "So, if (format) can't store or represent, just as an example, text
> > for images, then document (b) that uses images won't be able to be
> > compliant for that requirement ".
> >
> > Is too narrow a view of the requirement.
> >
> > "When a content format supports non-text objects, an encoding
> > mechanism shall be provided to associate non-text objects
> with textual
> > descriptions displayable by a user-agent."
> >
> > There is a higher level here. What is the task trying to achieve?
> >
> > The requirement to associate text with images is there so that an
> > individual that can't see the image can understand the content. The
> > requirement really is that the both the image and the text
> exist, and
> > the association between them is preserved so that when an arbitrary
> > user comes across the image, they also get the text.
> >
> > It is not necessarily a requirement that a format encode both the
> > image and the text, or indeed the association.
> >
> > For example GIF and HTML are both content formats. HTML does not
> > encode the pixel data, GIF does not encode the text. It is the
> > combination of the formats which provides the necessary
> information.
> > The association is provided by the src and alt attributes, which in
> > this case happens to be embedded in the HTML and the text is stored
> > locally however this is not the only configuration which would work.
> >
> > We could envision different systems, which would also fulfil the
> > purpose of the task; for example a metadata database which can
> > associate an image with the text for that image.
> > The text might be in another resource entirely (e.g. a
> resource fork
> > or a properties file). Or the text might be in metadata in
> the image
> > itself.
> >
> > Let us posit the GregorianDocumentFormat (GDF) which 'supports' a
> > non-text media format by including a reference to it using its ISAN
> > number.
> >
> > Authors associate text for the media object by indexing the
> text in a
> > data repository using the same ISAN, and storing the pixels for the
> > media object in the same database using the same ISAN.
> >
> > Thus GDF does not provide an encoding mechanism directly in
> terms of
> > bits in the document, but an encoding mechanism is
> certainly provided.
> > The GDF viewer software, if it can present the pixels can
> also present
> > the text.
> >
> > We can rephrase the requirement to avoid reference to a
> content format
> > as
> > follows:
> >
> > "All non-text objects that are presented to the user must
> have a text
> > alternative that presents equivalent information, except for the
> > situations listed below."
> >
> > Which is the non-text content provision for software. So the first
> > content provision is in fact logically redundant.
> >
> > This will also be true for all of the proposed content provisions.
> >
> >
> > Sean Hayes
> > Incubation Lab
> > Accessibility Business Unit
> > Microsoft
> >
> > Office: +44 118 909 5867,
> > Mobile: +44 7875 091385
> >
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > Hoffman, Allen
> > Sent: 21 September 2007 16:03
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > Chicken and egg:
> >
> > (a) is format, b is deliverable and/or document.
> >
> > So, if (format) can't store or represent, just as an
> example, text for
> > images, then document (b) that uses images won't be able to be
> > compliant for that requirement. so if a deliverable is
> represented as
> > compliant, but is in a underlying format that won't support the
> > ability to comply with a requirement, we know there is a problem
> > somewhere.
> >
> > The idea is to drive people to formats that can support more
> > accessibility over less, just as we do for other EIT.
> > currently we often get the push back that we can't comply
> because the
> > format won't do what you need, and "we have to use that
> format". This
> > format preselection is usually a false business need. Most of us
> > don't have a business need to use only one format. sometimes we do
> > but the format selection decision should not be made in a
> vacuum as it
> > bears directly on the accessibility of the end products so greatly.
> >
> >
> >
> >
> > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > Andrew Kirkpatrick
> > Sent: Friday, September 21, 2007 9:46 AM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > Allen,
> > I'm sorry, but your message is just a little too cryptic for me to
> > follow. Can you fill in "a" and "b" with actual items?
> > Thanks,
> > AWK
> >
> >
> >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > > Hoffman, Allen
> > > Sent: Friday, September 21, 2007 8:01 AM
> > > To: TEITAC Web/Software Subcommittee
> > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > >
> > > I think we're talking chicken and egg kinds of things.
> > >
> > > A can't do B if A doesn't allow for B.
> > > if you don't need B, its not important--but knowing what
> A can and
> > > can't do is important. -- channeling some Sean Hayes here.
> > >
> > >
> > >
> > >
> > > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> > >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > > Andrew Kirkpatrick
> > > Sent: Thursday, September 20, 2007 4:39 PM
> > > To: TEITAC Web/Software Subcommittee
> > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > >
> > > This is part of what I'm asking.
> > >
> > > Also a part of what I'm asking is due to differences in
> > what products
> > > support. A product may not use all of the accessibility
> > features in a
> >
> > > format, and more specifically, a product may not need to
> use all of
> > > the support available in a format, depending on the use of the
> > > product.
> > > Imagine a format that complies with everything except the format
> > > doesn't allow for equivalents for images. If a government agency
> > > knows that the product doesn't create images in its output, even
> > > though the format doesn't support this, it doesn't matter
> for that
> > > product - what is important is the output of the product.
> > >
> > > AWK
> > >
> > > > -----Original Message-----
> > > > From: = EMAIL ADDRESS REMOVED =
> > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> > > Behalf Of Jim
> > > > Tobias
> > > > Sent: Thursday, September 20, 2007 3:31 PM
> > > > To: 'TEITAC Web/Software Subcommittee'
> > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > >
> > > > I don't see why the entire format info would have to be in
> > > a VPAT if
> > > > it's a public, standard format used by the authoring tool in a
> > > > standard way. If the tool deviates from the format in any
> > > important
> > > > way that would have to be documented.
> > > >
> > > > Am I missing something?
> > > >
> > > > ***
> > > > Jim Tobias
> > > > Inclusive Technologies
> > > > +1.732.441.0831 v/tty
> > > > +1.908.907.2387 mobile
> > > > skype jimtobias
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Hoffman, Allen [mailto: = EMAIL ADDRESS REMOVED = ]
> > > > > Sent: Thursday, September 20, 2007 2:39 PM
> > > > > To: TEITAC Web/Software Subcommittee
> > > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > > >
> > > > > Point taken.
> > > > > Let me consider a bit and will post with a walk through
> > > of how this
> > > > > can work.
> > > > >
> > > > >
> > > > >
> > > > > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> > > > >
> > > > > -----Original Message-----
> > > > > From: = EMAIL ADDRESS REMOVED =
> > > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> > Behalf Of
> > > > > Andrew Kirkpatrick
> > > > > Sent: Thursday, September 20, 2007 2:36 PM
> > > > > To: TEITAC Web/Software Subcommittee
> > > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > > >
> > > > > This seems like a lot of additional overhead for a mere
> > > > sanity check.
> > > > > I'm envisioning a lot of confusion for procurement people
> > > when they
> > > > > receive a 16 page VPAT for a product that outputs in 5
> > different
> > > > > formats and needs to include information about the
> > > > capabilities of the
> > > > > format for each. Do you really expect that these people will
> > > > > cross-reference the product section 3 VPAT information
> > > against the
> > > > > various section 8 items for the format because it might
> > > reveal that
> > > > > the product VPAT author is declaring something that they
> > > shouldn't?
> > > > >
> > > > > AWK
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: = EMAIL ADDRESS REMOVED =
> > > > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> > > Behalf Of
> > > > > > Hoffman, Allen
> > > > > > Sent: Thursday, September 20, 2007 1:07 PM
> > > > > > To: TEITAC Web/Software Subcommittee
> > > > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > > > >
> > > > > > Look at it as a sanity check.
> > > > > > If you state that, for example, you meet the language
> > > > > requirement in
> > > > > > 3, but select a format that doesn't include that capacity,
> > > > > something
> > > > > > is wrong.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: = EMAIL ADDRESS REMOVED =
> > > > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> > > Behalf Of
> > > > > > Andrew Kirkpatrick
> > > > > > Sent: Thursday, September 20, 2007 1:04 PM
> > > > > > To: TEITAC Web/Software Subcommittee
> > > > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > > > >
> > > > > > Allen,
> > > > > >
> > > > > > You state "When determining the most accessible product
> > > > > from a set of
> > > > > > more than one, the format information is provided in can
> > > > > determine if
> > > > > > other requirements can be met or not" but just
> > because a format
> > > > > > includes support for a particular standard it doesn't
> > > > mean that the
> > > > > > product that uses that format takes advantage of
> that support.
> > > > > >
> > > > > > How do you envision the support for the content formats
> > > > > being defined?
> > > > > > Does each content format have a VPAT? If so, who writes it?
> > > > > >
> > > > > > Part of my concern with the implementation of this section
> > > > > is that the
> > > > >
> > > > > > product is already reporting on how they support
> > standards that
> > > > > > overlap with the content format items - I'm not sure
> > > that it will
> > > > > > actually help in procurement decisions since the product
> > > > > needs to meet
> > > > >
> > > > > > the section 3 standards, and the section 8 standards not
> > > > only don't
> > > > > > bring anything new to the picture but they are not
> > necessarily
> > > > > > representative of the accessibility in the specific product.
> > > > > >
> > > > > > AWK
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: = EMAIL ADDRESS REMOVED =
> > > > > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> > > > Behalf Of
> > > > > > > Hoffman, Allen
> > > > > > > Sent: Thursday, September 20, 2007 11:43 AM
> > > > > > > To: TEITAC Web/Software Subcommittee
> > > > > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > > > > >
> > > > > > > All:
> > > > > > >
> > > > > > > Several people have raised questions related to how
> > > > > > provisions in 8.1
> > > > > > > relate to other sections. I think I'd like to propose an
> > > > > update to
> > > > > > > the draft for 09/14 to include some intro materials to
> > > > > > alleviate this
> > > > > > > concern, as it is obvious some connection is needed to
> > > > make this
> > > > > > > self-evident.
> > > > > > >
> > > > > > > So:
> > > > > > >
> > > > > > > Sections 3 and 6 above require that information
> > > > delivered must be
> > > > > > > presented meeting accessibility requirements. To
> > > > > accomplish this,
> > > > > > > information storage formats must allow for inclusion
> > > of certain
> > > > > > > accessibility related attributes and/or functionalities.
> > > > > > This section
> > > > > >
> > > > > > > describes the functional accessibility requirements for
> > > > > > such formats.
> > > > > > > When determining the most accessible product from a set of
> > > > > > more than
> > > > > > > one, the format information is provided in can
> > > > determine if other
> > > > > > > requirements can be met or not, and can be an important
> > > > > > factor in the
> > > > > > > final determination. Note:
> > > > > > > Formats which do not include some functionalities such as
> > > > > > the ability
> > > > > > > to represent synchronized media, would not be
> > subject to that
> > > > > > > provision.
> > > > > > >
> > > > > > >
> > > > > > >

From: Sean Hayes
Date: Sat, Sep 22 2007 5:55 AM
Subject: Re: intro for 8.1?

1 - covered by 3C

2 - covered by 6 A,B&C

4 - covered by 3K

5,6 & 7 - covered by 3N

8 - covered by 3M

9 - covered by 3C

10 - covered by a combination of 3N and 3C.

Sean Hayes
Incubation Lab
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,
Mobile: +44 7875 091385


-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim Tobias
Sent: 22 September 2007 12:42
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] intro for 8.1?

Sorry -- can you point to the specific provision(s) that would have the
effect you claim? I'm not seeing it.

***
Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias

From: Jim Tobias
Date: Sat, Sep 22 2007 6:15 AM
Subject: Re: intro for 8.1?

Thanks.

The first numbers you cite -- are those the 8.1 and 8.2 provisions? So "1"
is actually 8.1-A in the September 14 draft?

If that's the case, I still argue that although in a perfect world only the
final product should need evaluation, we are so far from that perfect world
that upstream provisions are still necessary. At the agency level they
prevent mischief during use, and at the industry level they support the
development and marketing of better tools. I don't see how they're overly
burdensome to either party. For example, we're not insisting that agencies
purchase tools that use the *most* accessible formats, nor are we imposing
oversight on format development itself.

If there were no lead paint, there would be no lead painted toys.

***
Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias


> -----Original Message-----
> From: Sean Hayes [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Saturday, September 22, 2007 7:53 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> 1 - covered by 3C
>
> 2 - covered by 6 A,B&C
>
> 4 - covered by 3K
>
> 5,6 & 7 - covered by 3N
>
> 8 - covered by 3M
>
> 9 - covered by 3C
>
> 10 - covered by a combination of 3N and 3C.
>
> Sean Hayes
> Incubation Lab
> Accessibility Business Unit
> Microsoft
>
> Office: +44 118 909 5867,
> Mobile: +44 7875 091385
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Jim Tobias
> Sent: 22 September 2007 12:42
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Sorry -- can you point to the specific provision(s) that
> would have the effect you claim? I'm not seeing it.
>
> ***
> Jim Tobias
> Inclusive Technologies
> +1.732.441.0831 v/tty
> +1.908.907.2387 mobile
> skype jimtobias
>
>
>

From: Sean Hayes
Date: Sat, Sep 22 2007 6:50 AM
Subject: Re: intro for 8.1?

Sorry, I was working from the Sept 3 draft.

One logical problem, if the primary leverage applied by agencies is procurement, is that the agency does not typically procure formats. It procures tools that generate and consume data encoded in those formats or maybe data encoded in formats.

The content rules might be replaced by a blanket clause:
"Agencies and their employees and agents must ensure electronic information is developed and maintained such that any receiving party can use software to access that information in a manner which complies with the software provisions."

Sean Hayes
Incubation Lab
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,
Mobile: +44 7875 091385


-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim Tobias
Sent: 22 September 2007 13:13
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] intro for 8.1?

Thanks.

The first numbers you cite -- are those the 8.1 and 8.2 provisions? So "1"
is actually 8.1-A in the September 14 draft?

If that's the case, I still argue that although in a perfect world only the
final product should need evaluation, we are so far from that perfect world
that upstream provisions are still necessary. At the agency level they
prevent mischief during use, and at the industry level they support the
development and marketing of better tools. I don't see how they're overly
burdensome to either party. For example, we're not insisting that agencies
purchase tools that use the *most* accessible formats, nor are we imposing
oversight on format development itself.

If there were no lead paint, there would be no lead painted toys.

***
Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias


> -----Original Message-----
> From: Sean Hayes [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Saturday, September 22, 2007 7:53 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> 1 - covered by 3C
>
> 2 - covered by 6 A,B&C
>
> 4 - covered by 3K
>
> 5,6 & 7 - covered by 3N
>
> 8 - covered by 3M
>
> 9 - covered by 3C
>
> 10 - covered by a combination of 3N and 3C.
>
> Sean Hayes
> Incubation Lab
> Accessibility Business Unit
> Microsoft
>
> Office: +44 118 909 5867,
> Mobile: +44 7875 091385
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Jim Tobias
> Sent: 22 September 2007 12:42
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Sorry -- can you point to the specific provision(s) that
> would have the effect you claim? I'm not seeing it.
>
> ***
> Jim Tobias
> Inclusive Technologies
> +1.732.441.0831 v/tty
> +1.908.907.2387 mobile
> skype jimtobias
>
>
>

From: Peter Korn
Date: Sat, Sep 22 2007 10:40 AM
Subject: Re: intro for 8.1?

Hi Sean,

I think it is true that today few if any U.S. Federal Government
agencies "procure" formats. But we have certainly seen several U.S.
States looking to formally standardize on document formats (cf.
Massachusetts). Likewise we have seen this in a number of European
countries. And I believe the U.S. Library of Congress and other
archiving organizations have been looking at like standardization.

As standardization is different from procurement, it may be that the
vehicle of Section 508 is not the right vehicle for this. But it seems
clear to me that an enumeration of the accessibility information that
must be "preservable" in/with a document format is an entirely
appropriate thing to write down, so that organizations that are looking
to standardize on some number of document formats know what they must
look for to ensure accessibility information is preservable in that format.

And I think this subcommittee has done a very nice job of doing that in
this collection of provisions.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> Sorry, I was working from the Sept 3 draft.
>
> One logical problem, if the primary leverage applied by agencies is procurement, is that the agency does not typically procure formats. It procures tools that generate and consume data encoded in those formats or maybe data encoded in formats.
>
> The content rules might be replaced by a blanket clause:
> "Agencies and their employees and agents must ensure electronic information is developed and maintained such that any receiving party can use software to access that information in a manner which complies with the software provisions."
>
> Sean Hayes
> Incubation Lab
> Accessibility Business Unit
> Microsoft
>
> Office: +44 118 909 5867,
> Mobile: +44 7875 091385
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim Tobias
> Sent: 22 September 2007 13:13
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Thanks.
>
> The first numbers you cite -- are those the 8.1 and 8.2 provisions? So "1"
> is actually 8.1-A in the September 14 draft?
>
> If that's the case, I still argue that although in a perfect world only the
> final product should need evaluation, we are so far from that perfect world
> that upstream provisions are still necessary. At the agency level they
> prevent mischief during use, and at the industry level they support the
> development and marketing of better tools. I don't see how they're overly
> burdensome to either party. For example, we're not insisting that agencies
> purchase tools that use the *most* accessible formats, nor are we imposing
> oversight on format development itself.
>
> If there were no lead paint, there would be no lead painted toys.
>
> ***
> Jim Tobias
> Inclusive Technologies
> +1.732.441.0831 v/tty
> +1.908.907.2387 mobile
> skype jimtobias
>
>
>
>> -----Original Message-----
>> From: Sean Hayes [mailto: = EMAIL ADDRESS REMOVED = ]
>> Sent: Saturday, September 22, 2007 7:53 AM
>> To: TEITAC Web/Software Subcommittee
>> Subject: Re: [teitac-websoftware] intro for 8.1?
>>
>> 1 - covered by 3C
>>
>> 2 - covered by 6 A,B&C
>>
>> 4 - covered by 3K
>>
>> 5,6 & 7 - covered by 3N
>>
>> 8 - covered by 3M
>>
>> 9 - covered by 3C
>>
>> 10 - covered by a combination of 3N and 3C.
>>
>> Sean Hayes
>> Incubation Lab
>> Accessibility Business Unit
>> Microsoft
>>
>> Office: +44 118 909 5867,
>> Mobile: +44 7875 091385
>>
>>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>> Of Jim Tobias
>> Sent: 22 September 2007 12:42
>> To: 'TEITAC Web/Software Subcommittee'
>> Subject: Re: [teitac-websoftware] intro for 8.1?
>>
>> Sorry -- can you point to the specific provision(s) that
>> would have the effect you claim? I'm not seeing it.
>>
>> ***
>> Jim Tobias
>> Inclusive Technologies
>> +1.732.441.0831 v/tty
>> +1.908.907.2387 mobile
>> skype jimtobias
>>
>>
>>

From: Sean Hayes
Date: Mon, Sep 24 2007 3:30 AM
Subject: Re: intro for 8.1?

Peter, I think your observations are valid in the context of office documents, but when we examine the wider scope of what the term "content format" covers I think we find problems.

It might be a valid tactic for an agency trying to meet 508 to voluntarily reduce their complexity burden by standardising on a specific set of technologies like OS, AT and office document types, however as you say that is out of the scope of 508. And even if so the agency would still need to be able to interoperate with content and systems outside of their control, as well as ensuring that the content which is created actually uses the accessibility features.

I agree that the group has done some good work on identifying the kind of information software needs to be able to obtain when using a content format in order to meet the operational provisions, but as I have already stated, it is not always appropriate to include that information directly in the content itself.

I'm not necessarily against recording the groups guidance somewhere but I think there are a number of problems with recording it as specific provisions within 508.

For one, there is the harmonisation problem, no other international standard has such provisions (possibly for the reasons I outline below), and that procurement applies to software and not content formats.

Then there is the issue that federal agencies between them record terabytes of information each year, including digital photographs; satellite imagery; cctv traffic, security, and other video; medical scans; geographical information and so on. These are all recorded in content formats which would not meet the proposed provisions on their own. Even if the agencies could employ the armies of operators it would require to create the descriptions, captions and annotations to make this information accessible; for practical, legal and forensic reasons, any such additional information would likely be entered into a media management database of some sort, not by altering the original content formats.

The proposed content rules while applicable in some specific cases, such as office document creation, do not encompass situations where the information is distributed over a set of content formats, such as HTML and PNG, or DV and timed text files. They also do not accommodate situations where data must necessarily live in an inaccessible format for some period and would be made accessible by later processing, like capturing a digital photograph.

So since the content provisions are already captured in a more general way by the provisions on software, and do not create the same operational constraints, I think we might be able to move the proposed content provisions into notes or guidance materials for the specific software provisions they relate to.

We also need to think about how the software rules apply to tools which are used in the conversion of inaccessible recorded media such as photographs and video, we may need to craft some specific exceptions otherwise we may inadvertently prevent the agencies from procuring tools such as Photoshop which are commonly used in the process of making such materials accessible.

Sean Hayes
Incubation Lab
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,
Mobile: +44 7875 091385


-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter Korn
Sent: 22 September 2007 17:37
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] intro for 8.1?

Hi Sean,

I think it is true that today few if any U.S. Federal Government
agencies "procure" formats. But we have certainly seen several U.S.
States looking to formally standardize on document formats (cf.
Massachusetts). Likewise we have seen this in a number of European
countries. And I believe the U.S. Library of Congress and other
archiving organizations have been looking at like standardization.

As standardization is different from procurement, it may be that the
vehicle of Section 508 is not the right vehicle for this. But it seems
clear to me that an enumeration of the accessibility information that
must be "preservable" in/with a document format is an entirely
appropriate thing to write down, so that organizations that are looking
to standardize on some number of document formats know what they must
look for to ensure accessibility information is preservable in that format.

And I think this subcommittee has done a very nice job of doing that in
this collection of provisions.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> Sorry, I was working from the Sept 3 draft.
>
> One logical problem, if the primary leverage applied by agencies is procurement, is that the agency does not typically procure formats. It procures tools that generate and consume data encoded in those formats or maybe data encoded in formats.
>
> The content rules might be replaced by a blanket clause:
> "Agencies and their employees and agents must ensure electronic information is developed and maintained such that any receiving party can use software to access that information in a manner which complies with the software provisions."
>
> Sean Hayes
> Incubation Lab
> Accessibility Business Unit
> Microsoft
>
> Office: +44 118 909 5867,
> Mobile: +44 7875 091385
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim Tobias
> Sent: 22 September 2007 13:13
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Thanks.
>
> The first numbers you cite -- are those the 8.1 and 8.2 provisions? So "1"
> is actually 8.1-A in the September 14 draft?
>
> If that's the case, I still argue that although in a perfect world only the
> final product should need evaluation, we are so far from that perfect world
> that upstream provisions are still necessary. At the agency level they
> prevent mischief during use, and at the industry level they support the
> development and marketing of better tools. I don't see how they're overly
> burdensome to either party. For example, we're not insisting that agencies
> purchase tools that use the *most* accessible formats, nor are we imposing
> oversight on format development itself.
>
> If there were no lead paint, there would be no lead painted toys.
>
> ***
> Jim Tobias
> Inclusive Technologies
> +1.732.441.0831 v/tty
> +1.908.907.2387 mobile
> skype jimtobias
>
>
>
>> -----Original Message-----
>> From: Sean Hayes [mailto: = EMAIL ADDRESS REMOVED = ]
>> Sent: Saturday, September 22, 2007 7:53 AM
>> To: TEITAC Web/Software Subcommittee
>> Subject: Re: [teitac-websoftware] intro for 8.1?
>>
>> 1 - covered by 3C
>>
>> 2 - covered by 6 A,B&C
>>
>> 4 - covered by 3K
>>
>> 5,6 & 7 - covered by 3N
>>
>> 8 - covered by 3M
>>
>> 9 - covered by 3C
>>
>> 10 - covered by a combination of 3N and 3C.
>>
>> Sean Hayes
>> Incubation Lab
>> Accessibility Business Unit
>> Microsoft
>>
>> Office: +44 118 909 5867,
>> Mobile: +44 7875 091385
>>
>>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
>> Of Jim Tobias
>> Sent: 22 September 2007 12:42
>> To: 'TEITAC Web/Software Subcommittee'
>> Subject: Re: [teitac-websoftware] intro for 8.1?
>>
>> Sorry -- can you point to the specific provision(s) that
>> would have the effect you claim? I'm not seeing it.
>>
>> ***
>> Jim Tobias
>> Inclusive Technologies
>> +1.732.441.0831 v/tty
>> +1.908.907.2387 mobile
>> skype jimtobias
>>
>>
>>

From: Hoffman, Allen
Date: Mon, Sep 24 2007 8:55 AM
Subject: Re: intro for 8.1?

Procurement applies to information and data.
information and data are delivered in some format.

So, for example, I buy a credit reporting service which provides daily
reports in IDF (inaccessible document format), and another vendor offers
that information in (adf), accessible document format. Now, you might
infer section 3 applies, but almost nobody will in the acquisition side
of things. Without this being an explicitly described item it will, and
has gotten lost and overlooked.

I think there certainly may be some scoping tweaking that would help,
but as one who as strived desperately over the past many years to
improve the accessibility of content, delivered by various software
mechanisms, I can say this link is what is missing and sorely requires
some strong mechanism to fix it. Much of the Access-Board's initial
question of how does Section 508 apply to "content" is based around
exactly this problem in the end. We have addressed the problem only in
the surface fashion if we leave out the format portion, and history
demonstrates that that approach doesn't work. if there is an interim
mechanism we can use I'd be all for exploring it.






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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Sean
Hayes
Sent: Monday, September 24, 2007 5:25 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] intro for 8.1?

Peter, I think your observations are valid in the context of office
documents, but when we examine the wider scope of what the term "content
format" covers I think we find problems.

It might be a valid tactic for an agency trying to meet 508 to
voluntarily reduce their complexity burden by standardising on a
specific set of technologies like OS, AT and office document types,
however as you say that is out of the scope of 508. And even if so the
agency would still need to be able to interoperate with content and
systems outside of their control, as well as ensuring that the content
which is created actually uses the accessibility features.

I agree that the group has done some good work on identifying the kind
of information software needs to be able to obtain when using a content
format in order to meet the operational provisions, but as I have
already stated, it is not always appropriate to include that information
directly in the content itself.

I'm not necessarily against recording the groups guidance somewhere but
I think there are a number of problems with recording it as specific
provisions within 508.

For one, there is the harmonisation problem, no other international
standard has such provisions (possibly for the reasons I outline below),
and that procurement applies to software and not content formats.

Then there is the issue that federal agencies between them record
terabytes of information each year, including digital photographs;
satellite imagery; cctv traffic, security, and other video; medical
scans; geographical information and so on. These are all recorded in
content formats which would not meet the proposed provisions on their
own. Even if the agencies could employ the armies of operators it would
require to create the descriptions, captions and annotations to make
this information accessible; for practical, legal and forensic reasons,
any such additional information would likely be entered into a media
management database of some sort, not by altering the original content
formats.

The proposed content rules while applicable in some specific cases, such
as office document creation, do not encompass situations where the
information is distributed over a set of content formats, such as HTML
and PNG, or DV and timed text files. They also do not accommodate
situations where data must necessarily live in an inaccessible format
for some period and would be made accessible by later processing, like
capturing a digital photograph.

So since the content provisions are already captured in a more general
way by the provisions on software, and do not create the same
operational constraints, I think we might be able to move the proposed
content provisions into notes or guidance materials for the specific
software provisions they relate to.

We also need to think about how the software rules apply to tools which
are used in the conversion of inaccessible recorded media such as
photographs and video, we may need to craft some specific exceptions
otherwise we may inadvertently prevent the agencies from procuring tools
such as Photoshop which are commonly used in the process of making such
materials accessible.

Sean Hayes
Incubation Lab
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,
Mobile: +44 7875 091385


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter
Korn
Sent: 22 September 2007 17:37
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] intro for 8.1?

Hi Sean,

I think it is true that today few if any U.S. Federal Government
agencies "procure" formats. But we have certainly seen several U.S.
States looking to formally standardize on document formats (cf.
Massachusetts). Likewise we have seen this in a number of European
countries. And I believe the U.S. Library of Congress and other
archiving organizations have been looking at like standardization.

As standardization is different from procurement, it may be that the
vehicle of Section 508 is not the right vehicle for this. But it seems
clear to me that an enumeration of the accessibility information that
must be "preservable" in/with a document format is an entirely
appropriate thing to write down, so that organizations that are looking
to standardize on some number of document formats know what they must
look for to ensure accessibility information is preservable in that
format.

And I think this subcommittee has done a very nice job of doing that in
this collection of provisions.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> Sorry, I was working from the Sept 3 draft.
>
> One logical problem, if the primary leverage applied by agencies is
procurement, is that the agency does not typically procure formats. It
procures tools that generate and consume data encoded in those formats
or maybe data encoded in formats.
>
> The content rules might be replaced by a blanket clause:
> "Agencies and their employees and agents must ensure electronic
information is developed and maintained such that any receiving party
can use software to access that information in a manner which complies
with the software provisions."
>
> Sean Hayes
> Incubation Lab
> Accessibility Business Unit
> Microsoft
>
> Office: +44 118 909 5867,
> Mobile: +44 7875 091385
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim
> Tobias
> Sent: 22 September 2007 13:13
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Thanks.
>
> The first numbers you cite -- are those the 8.1 and 8.2 provisions?
So "1"
> is actually 8.1-A in the September 14 draft?
>
> If that's the case, I still argue that although in a perfect world
> only the final product should need evaluation, we are so far from that

> perfect world that upstream provisions are still necessary. At the
> agency level they prevent mischief during use, and at the industry
> level they support the development and marketing of better tools. I
> don't see how they're overly burdensome to either party. For example,

> we're not insisting that agencies purchase tools that use the *most*
> accessible formats, nor are we imposing oversight on format
development itself.
>
> If there were no lead paint, there would be no lead painted toys.
>
> ***
> Jim Tobias
> Inclusive Technologies
> +1.732.441.0831 v/tty
> +1.908.907.2387 mobile
> skype jimtobias
>
>
>
>> -----Original Message-----
>> From: Sean Hayes [mailto: = EMAIL ADDRESS REMOVED = ]
>> Sent: Saturday, September 22, 2007 7:53 AM
>> To: TEITAC Web/Software Subcommittee
>> Subject: Re: [teitac-websoftware] intro for 8.1?
>>
>> 1 - covered by 3C
>>
>> 2 - covered by 6 A,B&C
>>
>> 4 - covered by 3K
>>
>> 5,6 & 7 - covered by 3N
>>
>> 8 - covered by 3M
>>
>> 9 - covered by 3C
>>
>> 10 - covered by a combination of 3N and 3C.
>>
>> Sean Hayes
>> Incubation Lab
>> Accessibility Business Unit
>> Microsoft
>>
>> Office: +44 118 909 5867,
>> Mobile: +44 7875 091385
>>
>>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim
>> Tobias
>> Sent: 22 September 2007 12:42
>> To: 'TEITAC Web/Software Subcommittee'
>> Subject: Re: [teitac-websoftware] intro for 8.1?
>>
>> Sorry -- can you point to the specific provision(s) that would have
>> the effect you claim? I'm not seeing it.
>>
>> ***
>> Jim Tobias
>> Inclusive Technologies
>> +1.732.441.0831 v/tty
>> +1.908.907.2387 mobile
>> skype jimtobias
>>
>>
>>

From: Hoffman, Allen
Date: Mon, Sep 24 2007 9:00 AM
Subject: Re: intro for 8.1?

Experience over the past years in the Federal government tells me this
is not a link "anyone" makes without being forced to do so. Format
selection is almost never based upon accessibility concerns, or even
includes accessibility requirements as a major selection factor. visual
appearance, authoring tool support, and personal familiarity are far
more prevalent as driving selection factors. Major formats of content
are still lacking key accessibility support, so in my opinion a real
selection preference for increased accessibility from the ground up is
needed. When more formats are on an even footing this item will fade as
a selection factor, but that's the whole driving point of Section 508.
Engineers etc do think that format should support requirements which
should support end-user interface requirements, but experience, again,
doesn't show that this really happens in the real world.






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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Sean
Hayes
Sent: Saturday, September 22, 2007 7:37 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] intro for 8.1?

That's OK, formats that don't carry accessibility information are
excluded from procurement by the software rules, because the software
cannot display the information if it's not present.

Sean Hayes
Incubation Lab
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,
Mobile: +44 7875 091385


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim
Tobias
Sent: 22 September 2007 12:33
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] intro for 8.1?

I disagree. Formats that cannot carry accessibility information should
be excluded from procurement so that they do not infect "use". 508 has
a hard time influencing anything other than procurement, and this is one
of the best opportunities to do so.

Formats are an important part of the accessibility value chain, and all
elements of that chain should be subjected to evaluation. That was the
original thinking behind addressing them, and it still seems correct to
me.

***
Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias


> -----Original Message-----
> From: Sean Hayes [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Saturday, September 22, 2007 3:50 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Yes. I believe they ought to be covered by the presentational and
> operational requirements of software, which induces the necessary
> requirement on the inputs to that software (as well as possibly on the

> operation of the software), without constraining the technical
> realisation of those requirements.
>
> Sean Hayes
> Incubation Lab
> Accessibility Business Unit
> Microsoft
>
> Office: +44 118 909 5867,
> Mobile: +44 7875 091385
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Andi
> Snow-Weaver
> Sent: 21 September 2007 18:20
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> So Sean, are you proposing that we don't need the content format
> provisions at all? I think that is also Andrew's point.
>
> Andi
>
>
>
>
> Sean Hayes
> <Sean.Hayes@micro
> soft.com>
> To
> Sent by: TEITAC Web/Software
> Subcommittee
> teitac-websoftwar
> < = EMAIL ADDRESS REMOVED =
> = EMAIL ADDRESS REMOVED = >
> itac.org
> cc
>
>
> Subject
> 09/21/2007 10:55 Re:
> [teitac-websoftware] intro for
> AM 8.1?
>
>
> Please respond to
> TEITAC
> Web/Software
> Subcommittee
> <teitac-websoftwa
> = EMAIL ADDRESS REMOVED =
> g>
>
>
>
>
>
>
> "So, if (format) can't store or represent, just as an example, text
> for images, then document (b) that uses images won't be able to be
> compliant for that requirement ".
>
> Is too narrow a view of the requirement.
>
> "When a content format supports non-text objects, an encoding
> mechanism shall be provided to associate non-text objects with textual

> descriptions displayable by a user-agent."
>
> There is a higher level here. What is the task trying to achieve?
>
> The requirement to associate text with images is there so that an
> individual that can't see the image can understand the content. The
> requirement really is that the both the image and the text exist, and
> the association between them is preserved so that when an arbitrary
> user comes across the image, they also get the text.
>
> It is not necessarily a requirement that a format encode both the
> image and the text, or indeed the association.
>
> For example GIF and HTML are both content formats. HTML does not
> encode the pixel data, GIF does not encode the text. It is the
> combination of the formats which provides the necessary information.
> The association is provided by the src and alt attributes, which in
> this case happens to be embedded in the HTML and the text is stored
> locally however this is not the only configuration which would work.
>
> We could envision different systems, which would also fulfil the
> purpose of the task; for example a metadata database which can
> associate an image with the text for that image.
> The text might be in another resource entirely (e.g. a resource fork
> or a properties file). Or the text might be in metadata in the image
> itself.
>
> Let us posit the GregorianDocumentFormat (GDF) which 'supports' a
> non-text media format by including a reference to it using its ISAN
> number.
>
> Authors associate text for the media object by indexing the text in a
> data repository using the same ISAN, and storing the pixels for the
> media object in the same database using the same ISAN.
>
> Thus GDF does not provide an encoding mechanism directly in terms of
> bits in the document, but an encoding mechanism is certainly provided.

> The GDF viewer software, if it can present the pixels can also present

> the text.
>
> We can rephrase the requirement to avoid reference to a content format

> as
> follows:
>
> "All non-text objects that are presented to the user must have a text
> alternative that presents equivalent information, except for the
> situations listed below."
>
> Which is the non-text content provision for software. So the first
> content provision is in fact logically redundant.
>
> This will also be true for all of the proposed content provisions.
>
>
> Sean Hayes
> Incubation Lab
> Accessibility Business Unit
> Microsoft
>
> Office: +44 118 909 5867,
> Mobile: +44 7875 091385
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Hoffman, Allen
> Sent: 21 September 2007 16:03
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Chicken and egg:
>
> (a) is format, b is deliverable and/or document.
>
> So, if (format) can't store or represent, just as an example, text for

> images, then document (b) that uses images won't be able to be
> compliant for that requirement. so if a deliverable is represented as

> compliant, but is in a underlying format that won't support the
> ability to comply with a requirement, we know there is a problem
> somewhere.
>
> The idea is to drive people to formats that can support more
> accessibility over less, just as we do for other EIT.
> currently we often get the push back that we can't comply because the
> format won't do what you need, and "we have to use that format". This

> format preselection is usually a false business need. Most of us
> don't have a business need to use only one format. sometimes we do
> but the format selection decision should not be made in a vacuum as it

> bears directly on the accessibility of the end products so greatly.
>
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Andrew Kirkpatrick
> Sent: Friday, September 21, 2007 9:46 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Allen,
> I'm sorry, but your message is just a little too cryptic for me to
> follow. Can you fill in "a" and "b" with actual items?
> Thanks,
> AWK
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > Hoffman, Allen
> > Sent: Friday, September 21, 2007 8:01 AM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > I think we're talking chicken and egg kinds of things.
> >
> > A can't do B if A doesn't allow for B.
> > if you don't need B, its not important--but knowing what A can and
> > can't do is important. -- channeling some Sean Hayes here.
> >
> >
> >
> >
> > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > Andrew Kirkpatrick
> > Sent: Thursday, September 20, 2007 4:39 PM
> > To: TEITAC Web/Software Subcommittee
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > This is part of what I'm asking.
> >
> > Also a part of what I'm asking is due to differences in
> what products
> > support. A product may not use all of the accessibility
> features in a
>
> > format, and more specifically, a product may not need to use all of
> > the support available in a format, depending on the use of the
> > product.
> > Imagine a format that complies with everything except the format
> > doesn't allow for equivalents for images. If a government agency
> > knows that the product doesn't create images in its output, even
> > though the format doesn't support this, it doesn't matter for that
> > product - what is important is the output of the product.
> >
> > AWK
> >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> > Behalf Of Jim
> > > Tobias
> > > Sent: Thursday, September 20, 2007 3:31 PM
> > > To: 'TEITAC Web/Software Subcommittee'
> > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > >
> > > I don't see why the entire format info would have to be in
> > a VPAT if
> > > it's a public, standard format used by the authoring tool in a
> > > standard way. If the tool deviates from the format in any
> > important
> > > way that would have to be documented.
> > >
> > > Am I missing something?
> > >
> > > ***
> > > Jim Tobias
> > > Inclusive Technologies
> > > +1.732.441.0831 v/tty
> > > +1.908.907.2387 mobile
> > > skype jimtobias
> > >
> > >
> > > > -----Original Message-----
> > > > From: Hoffman, Allen [mailto: = EMAIL ADDRESS REMOVED = ]
> > > > Sent: Thursday, September 20, 2007 2:39 PM
> > > > To: TEITAC Web/Software Subcommittee
> > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > >
> > > > Point taken.
> > > > Let me consider a bit and will post with a walk through
> > of how this
> > > > can work.
> > > >
> > > >
> > > >
> > > > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> > > >
> > > > -----Original Message-----
> > > > From: = EMAIL ADDRESS REMOVED =
> > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of
> > > > Andrew Kirkpatrick
> > > > Sent: Thursday, September 20, 2007 2:36 PM
> > > > To: TEITAC Web/Software Subcommittee
> > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > >
> > > > This seems like a lot of additional overhead for a mere
> > > sanity check.
> > > > I'm envisioning a lot of confusion for procurement people
> > when they
> > > > receive a 16 page VPAT for a product that outputs in 5
> different
> > > > formats and needs to include information about the
> > > capabilities of the
> > > > format for each. Do you really expect that these people will
> > > > cross-reference the product section 3 VPAT information
> > against the
> > > > various section 8 items for the format because it might
> > reveal that
> > > > the product VPAT author is declaring something that they
> > shouldn't?
> > > >
> > > > AWK
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: = EMAIL ADDRESS REMOVED =
> > > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> > Behalf Of
> > > > > Hoffman, Allen
> > > > > Sent: Thursday, September 20, 2007 1:07 PM
> > > > > To: TEITAC Web/Software Subcommittee
> > > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > > >
> > > > > Look at it as a sanity check.
> > > > > If you state that, for example, you meet the language
> > > > requirement in
> > > > > 3, but select a format that doesn't include that capacity,
> > > > something
> > > > > is wrong.
> > > > >
> > > > >
> > > > >
> > > > > Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> > > > >
> > > > > -----Original Message-----
> > > > > From: = EMAIL ADDRESS REMOVED =
> > > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> > Behalf Of
> > > > > Andrew Kirkpatrick
> > > > > Sent: Thursday, September 20, 2007 1:04 PM
> > > > > To: TEITAC Web/Software Subcommittee
> > > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > > >
> > > > > Allen,
> > > > >
> > > > > You state "When determining the most accessible product
> > > > from a set of
> > > > > more than one, the format information is provided in can
> > > > determine if
> > > > > other requirements can be met or not" but just
> because a format
> > > > > includes support for a particular standard it doesn't
> > > mean that the
> > > > > product that uses that format takes advantage of that support.
> > > > >
> > > > > How do you envision the support for the content formats
> > > > being defined?
> > > > > Does each content format have a VPAT? If so, who writes it?
> > > > >
> > > > > Part of my concern with the implementation of this section
> > > > is that the
> > > >
> > > > > product is already reporting on how they support
> standards that
> > > > > overlap with the content format items - I'm not sure
> > that it will
> > > > > actually help in procurement decisions since the product
> > > > needs to meet
> > > >
> > > > > the section 3 standards, and the section 8 standards not
> > > only don't
> > > > > bring anything new to the picture but they are not
> necessarily
> > > > > representative of the accessibility in the specific product.
> > > > >
> > > > > AWK
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: = EMAIL ADDRESS REMOVED =
> > > > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> > > Behalf Of
> > > > > > Hoffman, Allen
> > > > > > Sent: Thursday, September 20, 2007 11:43 AM
> > > > > > To: TEITAC Web/Software Subcommittee
> > > > > > Subject: Re: [teitac-websoftware] intro for 8.1?
> > > > > >
> > > > > > All:
> > > > > >
> > > > > > Several people have raised questions related to how
> > > > > provisions in 8.1
> > > > > > relate to other sections. I think I'd like to propose an
> > > > update to
> > > > > > the draft for 09/14 to include some intro materials to
> > > > > alleviate this
> > > > > > concern, as it is obvious some connection is needed to
> > > make this
> > > > > > self-evident.
> > > > > >
> > > > > > So:
> > > > > >
> > > > > > Sections 3 and 6 above require that information
> > > delivered must be
> > > > > > presented meeting accessibility requirements. To
> > > > accomplish this,
> > > > > > information storage formats must allow for inclusion
> > of certain
> > > > > > accessibility related attributes and/or functionalities.
> > > > > This section
> > > > >
> > > > > > describes the functional accessibility requirements for
> > > > > such formats.
> > > > > > When determining the most accessible product from a set of
> > > > > more than
> > > > > > one, the format information is provided in can
> > > determine if other
> > > > > > requirements can be met or not, and can be an important
> > > > > factor in the
> > > > > > final determination. Note:
> > > > > > Formats which do not include some functionalities such as
> > > > > the ability
> > > > > > to represent synchronized media, would not be
> subject to that
> > > > > > provision.
> > > > > >
> > > > > >
> > > > > >

From: Jim Tobias
Date: Mon, Sep 24 2007 9:05 AM
Subject: Re: intro for 8.1?

Thanks, Allen -- you've made the need for content format provisions very
clear.

***
Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias


> -----Original Message-----
> From: Hoffman, Allen [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Monday, September 24, 2007 8:16 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Procurement applies to information and data.
> information and data are delivered in some format.
>
> So, for example, I buy a credit reporting service which
> provides daily reports in IDF (inaccessible document format),
> and another vendor offers that information in (adf),
> accessible document format. Now, you might infer section 3
> applies, but almost nobody will in the acquisition side of
> things. Without this being an explicitly described item it
> will, and has gotten lost and overlooked.
>
> I think there certainly may be some scoping tweaking that
> would help, but as one who as strived desperately over the
> past many years to improve the accessibility of content,
> delivered by various software mechanisms, I can say this link
> is what is missing and sorely requires some strong mechanism
> to fix it. Much of the Access-Board's initial question of
> how does Section 508 apply to "content" is based around
> exactly this problem in the end. We have addressed the
> problem only in the surface fashion if we leave out the
> format portion, and history demonstrates that that approach
> doesn't work. if there is an interim mechanism we can use
> I'd be all for exploring it.
>
>
>
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Sean Hayes
> Sent: Monday, September 24, 2007 5:25 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Peter, I think your observations are valid in the context of
> office documents, but when we examine the wider scope of what
> the term "content format" covers I think we find problems.
>
> It might be a valid tactic for an agency trying to meet 508
> to voluntarily reduce their complexity burden by
> standardising on a specific set of technologies like OS, AT
> and office document types, however as you say that is out of
> the scope of 508. And even if so the agency would still need
> to be able to interoperate with content and systems outside
> of their control, as well as ensuring that the content which
> is created actually uses the accessibility features.
>
> I agree that the group has done some good work on identifying
> the kind of information software needs to be able to obtain
> when using a content format in order to meet the operational
> provisions, but as I have already stated, it is not always
> appropriate to include that information directly in the
> content itself.
>
> I'm not necessarily against recording the groups guidance
> somewhere but I think there are a number of problems with
> recording it as specific provisions within 508.
>
> For one, there is the harmonisation problem, no other
> international standard has such provisions (possibly for the
> reasons I outline below), and that procurement applies to
> software and not content formats.
>
> Then there is the issue that federal agencies between them
> record terabytes of information each year, including digital
> photographs; satellite imagery; cctv traffic, security, and
> other video; medical scans; geographical information and so
> on. These are all recorded in content formats which would not
> meet the proposed provisions on their own. Even if the
> agencies could employ the armies of operators it would
> require to create the descriptions, captions and annotations
> to make this information accessible; for practical, legal and
> forensic reasons, any such additional information would
> likely be entered into a media management database of some
> sort, not by altering the original content formats.
>
> The proposed content rules while applicable in some specific
> cases, such as office document creation, do not encompass
> situations where the information is distributed over a set of
> content formats, such as HTML and PNG, or DV and timed text
> files. They also do not accommodate situations where data
> must necessarily live in an inaccessible format for some
> period and would be made accessible by later processing, like
> capturing a digital photograph.
>
> So since the content provisions are already captured in a
> more general way by the provisions on software, and do not
> create the same operational constraints, I think we might be
> able to move the proposed content provisions into notes or
> guidance materials for the specific software provisions they
> relate to.
>
> We also need to think about how the software rules apply to
> tools which are used in the conversion of inaccessible
> recorded media such as photographs and video, we may need to
> craft some specific exceptions otherwise we may inadvertently
> prevent the agencies from procuring tools such as Photoshop
> which are commonly used in the process of making such
> materials accessible.
>
> Sean Hayes
> Incubation Lab
> Accessibility Business Unit
> Microsoft
>
> Office: +44 118 909 5867,
> Mobile: +44 7875 091385
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Peter Korn
> Sent: 22 September 2007 17:37
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Hi Sean,
>
> I think it is true that today few if any U.S. Federal
> Government agencies "procure" formats. But we have certainly
> seen several U.S.
> States looking to formally standardize on document formats (cf.
> Massachusetts). Likewise we have seen this in a number of
> European countries. And I believe the U.S. Library of
> Congress and other archiving organizations have been looking
> at like standardization.
>
> As standardization is different from procurement, it may be
> that the vehicle of Section 508 is not the right vehicle for
> this. But it seems clear to me that an enumeration of the
> accessibility information that must be "preservable" in/with
> a document format is an entirely appropriate thing to write
> down, so that organizations that are looking to standardize
> on some number of document formats know what they must look
> for to ensure accessibility information is preservable in that format.
>
> And I think this subcommittee has done a very nice job of
> doing that in this collection of provisions.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
> > Sorry, I was working from the Sept 3 draft.
> >
> > One logical problem, if the primary leverage applied by agencies is
> procurement, is that the agency does not typically procure
> formats. It procures tools that generate and consume data
> encoded in those formats or maybe data encoded in formats.
> >
> > The content rules might be replaced by a blanket clause:
> > "Agencies and their employees and agents must ensure electronic
> information is developed and maintained such that any
> receiving party can use software to access that information
> in a manner which complies with the software provisions."
> >
> > Sean Hayes
> > Incubation Lab
> > Accessibility Business Unit
> > Microsoft
> >
> > Office: +44 118 909 5867,
> > Mobile: +44 7875 091385
> >
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> > Tobias
> > Sent: 22 September 2007 13:13
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > Thanks.
> >
> > The first numbers you cite -- are those the 8.1 and 8.2 provisions?
> So "1"
> > is actually 8.1-A in the September 14 draft?
> >
> > If that's the case, I still argue that although in a perfect world
> > only the final product should need evaluation, we are so
> far from that
>
> > perfect world that upstream provisions are still necessary. At the
> > agency level they prevent mischief during use, and at the industry
> > level they support the development and marketing of better
> tools. I
> > don't see how they're overly burdensome to either party.
> For example,
>
> > we're not insisting that agencies purchase tools that use
> the *most*
> > accessible formats, nor are we imposing oversight on format
> development itself.
> >
> > If there were no lead paint, there would be no lead painted toys.
> >
> > ***
> > Jim Tobias
> > Inclusive Technologies
> > +1.732.441.0831 v/tty
> > +1.908.907.2387 mobile
> > skype jimtobias
> >
> >
> >
> >> -----Original Message-----
> >> From: Sean Hayes [mailto: = EMAIL ADDRESS REMOVED = ]
> >> Sent: Saturday, September 22, 2007 7:53 AM
> >> To: TEITAC Web/Software Subcommittee
> >> Subject: Re: [teitac-websoftware] intro for 8.1?
> >>
> >> 1 - covered by 3C
> >>
> >> 2 - covered by 6 A,B&C
> >>
> >> 4 - covered by 3K
> >>
> >> 5,6 & 7 - covered by 3N
> >>
> >> 8 - covered by 3M
> >>
> >> 9 - covered by 3C
> >>
> >> 10 - covered by a combination of 3N and 3C.
> >>
> >> Sean Hayes
> >> Incubation Lab
> >> Accessibility Business Unit
> >> Microsoft
> >>
> >> Office: +44 118 909 5867,
> >> Mobile: +44 7875 091385
> >>
> >>
> >> -----Original Message-----
> >> From: = EMAIL ADDRESS REMOVED =
> >> [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> >> Tobias
> >> Sent: 22 September 2007 12:42
> >> To: 'TEITAC Web/Software Subcommittee'
> >> Subject: Re: [teitac-websoftware] intro for 8.1?
> >>
> >> Sorry -- can you point to the specific provision(s) that
> would have
> >> the effect you claim? I'm not seeing it.
> >>
> >> ***
> >> Jim Tobias
> >> Inclusive Technologies
> >> +1.732.441.0831 v/tty
> >> +1.908.907.2387 mobile
> >> skype jimtobias
> >>
> >>
> >>

From: Gregg Vanderheiden
Date: Mon, Sep 24 2007 9:45 AM
Subject: Re: intro for 8.1?

This is similar to the "accessibility supported" concept in WCAG.

In WCAG however the technologies must actually be supported by at least some
AT.

In 508 as written - (as I understand it) all that is required is that there
be an API for the format to pass 508. There does not have to be any AT that
actually works with the Format.

1) do I understand this correctly?
2) do we want to rewrite slightly so that there has to be actual AT that
works with the format?

If I misunderstood and AT is required we should put a statement somewhere to
make it clear since it is ambiguous and some feel that AT is not required.

thanks


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



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Hoffman, Allen
> Sent: Monday, September 24, 2007 7:16 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Procurement applies to information and data.
> information and data are delivered in some format.
>
> So, for example, I buy a credit reporting service which
> provides daily reports in IDF (inaccessible document format),
> and another vendor offers that information in (adf),
> accessible document format. Now, you might infer section 3
> applies, but almost nobody will in the acquisition side of
> things. Without this being an explicitly described item it
> will, and has gotten lost and overlooked.
>
> I think there certainly may be some scoping tweaking that
> would help, but as one who as strived desperately over the
> past many years to improve the accessibility of content,
> delivered by various software mechanisms, I can say this link
> is what is missing and sorely requires some strong mechanism
> to fix it. Much of the Access-Board's initial question of
> how does Section 508 apply to "content" is based around
> exactly this problem in the end. We have addressed the
> problem only in the surface fashion if we leave out the
> format portion, and history demonstrates that that approach
> doesn't work. if there is an interim mechanism we can use
> I'd be all for exploring it.
>
>
>
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Sean Hayes
> Sent: Monday, September 24, 2007 5:25 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Peter, I think your observations are valid in the context of
> office documents, but when we examine the wider scope of what
> the term "content format" covers I think we find problems.
>
> It might be a valid tactic for an agency trying to meet 508
> to voluntarily reduce their complexity burden by
> standardising on a specific set of technologies like OS, AT
> and office document types, however as you say that is out of
> the scope of 508. And even if so the agency would still need
> to be able to interoperate with content and systems outside
> of their control, as well as ensuring that the content which
> is created actually uses the accessibility features.
>
> I agree that the group has done some good work on identifying
> the kind of information software needs to be able to obtain
> when using a content format in order to meet the operational
> provisions, but as I have already stated, it is not always
> appropriate to include that information directly in the
> content itself.
>
> I'm not necessarily against recording the groups guidance
> somewhere but I think there are a number of problems with
> recording it as specific provisions within 508.
>
> For one, there is the harmonisation problem, no other
> international standard has such provisions (possibly for the
> reasons I outline below), and that procurement applies to
> software and not content formats.
>
> Then there is the issue that federal agencies between them
> record terabytes of information each year, including digital
> photographs; satellite imagery; cctv traffic, security, and
> other video; medical scans; geographical information and so
> on. These are all recorded in content formats which would not
> meet the proposed provisions on their own. Even if the
> agencies could employ the armies of operators it would
> require to create the descriptions, captions and annotations
> to make this information accessible; for practical, legal and
> forensic reasons, any such additional information would
> likely be entered into a media management database of some
> sort, not by altering the original content formats.
>
> The proposed content rules while applicable in some specific
> cases, such as office document creation, do not encompass
> situations where the information is distributed over a set of
> content formats, such as HTML and PNG, or DV and timed text
> files. They also do not accommodate situations where data
> must necessarily live in an inaccessible format for some
> period and would be made accessible by later processing, like
> capturing a digital photograph.
>
> So since the content provisions are already captured in a
> more general way by the provisions on software, and do not
> create the same operational constraints, I think we might be
> able to move the proposed content provisions into notes or
> guidance materials for the specific software provisions they
> relate to.
>
> We also need to think about how the software rules apply to
> tools which are used in the conversion of inaccessible
> recorded media such as photographs and video, we may need to
> craft some specific exceptions otherwise we may inadvertently
> prevent the agencies from procuring tools such as Photoshop
> which are commonly used in the process of making such
> materials accessible.
>
> Sean Hayes
> Incubation Lab
> Accessibility Business Unit
> Microsoft
>
> Office: +44 118 909 5867,
> Mobile: +44 7875 091385
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Peter Korn
> Sent: 22 September 2007 17:37
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Hi Sean,
>
> I think it is true that today few if any U.S. Federal
> Government agencies "procure" formats. But we have certainly
> seen several U.S.
> States looking to formally standardize on document formats (cf.
> Massachusetts). Likewise we have seen this in a number of
> European countries. And I believe the U.S. Library of
> Congress and other archiving organizations have been looking
> at like standardization.
>
> As standardization is different from procurement, it may be
> that the vehicle of Section 508 is not the right vehicle for
> this. But it seems clear to me that an enumeration of the
> accessibility information that must be "preservable" in/with
> a document format is an entirely appropriate thing to write
> down, so that organizations that are looking to standardize
> on some number of document formats know what they must look
> for to ensure accessibility information is preservable in that format.
>
> And I think this subcommittee has done a very nice job of
> doing that in this collection of provisions.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
> > Sorry, I was working from the Sept 3 draft.
> >
> > One logical problem, if the primary leverage applied by agencies is
> procurement, is that the agency does not typically procure
> formats. It procures tools that generate and consume data
> encoded in those formats or maybe data encoded in formats.
> >
> > The content rules might be replaced by a blanket clause:
> > "Agencies and their employees and agents must ensure electronic
> information is developed and maintained such that any
> receiving party can use software to access that information
> in a manner which complies with the software provisions."
> >
> > Sean Hayes
> > Incubation Lab
> > Accessibility Business Unit
> > Microsoft
> >
> > Office: +44 118 909 5867,
> > Mobile: +44 7875 091385
> >
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> > Tobias
> > Sent: 22 September 2007 13:13
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > Thanks.
> >
> > The first numbers you cite -- are those the 8.1 and 8.2 provisions?
> So "1"
> > is actually 8.1-A in the September 14 draft?
> >
> > If that's the case, I still argue that although in a perfect world
> > only the final product should need evaluation, we are so
> far from that
>
> > perfect world that upstream provisions are still necessary. At the
> > agency level they prevent mischief during use, and at the industry
> > level they support the development and marketing of better
> tools. I
> > don't see how they're overly burdensome to either party.
> For example,
>
> > we're not insisting that agencies purchase tools that use
> the *most*
> > accessible formats, nor are we imposing oversight on format
> development itself.
> >
> > If there were no lead paint, there would be no lead painted toys.
> >
> > ***
> > Jim Tobias
> > Inclusive Technologies
> > +1.732.441.0831 v/tty
> > +1.908.907.2387 mobile
> > skype jimtobias
> >
> >
> >
> >> -----Original Message-----
> >> From: Sean Hayes [mailto: = EMAIL ADDRESS REMOVED = ]
> >> Sent: Saturday, September 22, 2007 7:53 AM
> >> To: TEITAC Web/Software Subcommittee
> >> Subject: Re: [teitac-websoftware] intro for 8.1?
> >>
> >> 1 - covered by 3C
> >>
> >> 2 - covered by 6 A,B&C
> >>
> >> 4 - covered by 3K
> >>
> >> 5,6 & 7 - covered by 3N
> >>
> >> 8 - covered by 3M
> >>
> >> 9 - covered by 3C
> >>
> >> 10 - covered by a combination of 3N and 3C.
> >>
> >> Sean Hayes
> >> Incubation Lab
> >> Accessibility Business Unit
> >> Microsoft
> >>
> >> Office: +44 118 909 5867,
> >> Mobile: +44 7875 091385
> >>
> >>
> >> -----Original Message-----
> >> From: = EMAIL ADDRESS REMOVED =
> >> [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> >> Tobias
> >> Sent: 22 September 2007 12:42
> >> To: 'TEITAC Web/Software Subcommittee'
> >> Subject: Re: [teitac-websoftware] intro for 8.1?
> >>
> >> Sorry -- can you point to the specific provision(s) that
> would have
> >> the effect you claim? I'm not seeing it.
> >>
> >> ***
> >> Jim Tobias
> >> Inclusive Technologies
> >> +1.732.441.0831 v/tty
> >> +1.908.907.2387 mobile
> >> skype jimtobias
> >>
> >>
> >>

From: Sean Hayes
Date: Mon, Sep 24 2007 9:50 AM
Subject: Re: intro for 8.1?

Allen, I agree with you on the need. What I'm having a problem with is the proposed solution.

In addition to the problems I've already outlined, Just because a vendor offers information in a format adf, does not mean the vendor has filled in the blanks correctly so that the purchased information is in fact accessible.

If a vendor offers the "news in pictures" as a set of JPEG's and provides text equivalents as an HTML file with links to the images containing the alt text, is he prevented from selling the JPEG's to a federal agency? The current rules would say yes (assuming we interpret them to mean "information encoded in a content format", rather than "content format").

My proposal was to move the current content format proposals into notes on the software provisions, to keep the discussion concrete, here is what it might look like for 'Non-text Objects':

3-F - Non-text Objects
Non-text Objects: All non-text objects that are presented to the user must have a text alternative that presents equivalent information, except for the situations listed below.
Note: In order to achieve this provision, such non text objects in data operated on by the software must be associated with equivalent textual descriptions that the software can obtain as readily as it can obtain the non-text object itself.

Sean Hayes
Incubation Lab
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,
Mobile: +44 7875 091385

-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Hoffman, Allen
Sent: 24 September 2007 13:16
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] intro for 8.1?

Procurement applies to information and data.
information and data are delivered in some format.

So, for example, I buy a credit reporting service which provides daily
reports in IDF (inaccessible document format), and another vendor offers
that information in (adf), accessible document format. Now, you might
infer section 3 applies, but almost nobody will in the acquisition side
of things. Without this being an explicitly described item it will, and
has gotten lost and overlooked.

I think there certainly may be some scoping tweaking that would help,
but as one who as strived desperately over the past many years to
improve the accessibility of content, delivered by various software
mechanisms, I can say this link is what is missing and sorely requires
some strong mechanism to fix it. Much of the Access-Board's initial
question of how does Section 508 apply to "content" is based around
exactly this problem in the end. We have addressed the problem only in
the surface fashion if we leave out the format portion, and history
demonstrates that that approach doesn't work. if there is an interim
mechanism we can use I'd be all for exploring it.






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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Sean
Hayes
Sent: Monday, September 24, 2007 5:25 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] intro for 8.1?

Peter, I think your observations are valid in the context of office
documents, but when we examine the wider scope of what the term "content
format" covers I think we find problems.

It might be a valid tactic for an agency trying to meet 508 to
voluntarily reduce their complexity burden by standardising on a
specific set of technologies like OS, AT and office document types,
however as you say that is out of the scope of 508. And even if so the
agency would still need to be able to interoperate with content and
systems outside of their control, as well as ensuring that the content
which is created actually uses the accessibility features.

I agree that the group has done some good work on identifying the kind
of information software needs to be able to obtain when using a content
format in order to meet the operational provisions, but as I have
already stated, it is not always appropriate to include that information
directly in the content itself.

I'm not necessarily against recording the groups guidance somewhere but
I think there are a number of problems with recording it as specific
provisions within 508.

For one, there is the harmonisation problem, no other international
standard has such provisions (possibly for the reasons I outline below),
and that procurement applies to software and not content formats.

Then there is the issue that federal agencies between them record
terabytes of information each year, including digital photographs;
satellite imagery; cctv traffic, security, and other video; medical
scans; geographical information and so on. These are all recorded in
content formats which would not meet the proposed provisions on their
own. Even if the agencies could employ the armies of operators it would
require to create the descriptions, captions and annotations to make
this information accessible; for practical, legal and forensic reasons,
any such additional information would likely be entered into a media
management database of some sort, not by altering the original content
formats.

The proposed content rules while applicable in some specific cases, such
as office document creation, do not encompass situations where the
information is distributed over a set of content formats, such as HTML
and PNG, or DV and timed text files. They also do not accommodate
situations where data must necessarily live in an inaccessible format
for some period and would be made accessible by later processing, like
capturing a digital photograph.

So since the content provisions are already captured in a more general
way by the provisions on software, and do not create the same
operational constraints, I think we might be able to move the proposed
content provisions into notes or guidance materials for the specific
software provisions they relate to.

We also need to think about how the software rules apply to tools which
are used in the conversion of inaccessible recorded media such as
photographs and video, we may need to craft some specific exceptions
otherwise we may inadvertently prevent the agencies from procuring tools
such as Photoshop which are commonly used in the process of making such
materials accessible.

Sean Hayes
Incubation Lab
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,
Mobile: +44 7875 091385


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter
Korn
Sent: 22 September 2007 17:37
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] intro for 8.1?

Hi Sean,

I think it is true that today few if any U.S. Federal Government
agencies "procure" formats. But we have certainly seen several U.S.
States looking to formally standardize on document formats (cf.
Massachusetts). Likewise we have seen this in a number of European
countries. And I believe the U.S. Library of Congress and other
archiving organizations have been looking at like standardization.

As standardization is different from procurement, it may be that the
vehicle of Section 508 is not the right vehicle for this. But it seems
clear to me that an enumeration of the accessibility information that
must be "preservable" in/with a document format is an entirely
appropriate thing to write down, so that organizations that are looking
to standardize on some number of document formats know what they must
look for to ensure accessibility information is preservable in that
format.

And I think this subcommittee has done a very nice job of doing that in
this collection of provisions.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

> Sorry, I was working from the Sept 3 draft.
>
> One logical problem, if the primary leverage applied by agencies is
procurement, is that the agency does not typically procure formats. It
procures tools that generate and consume data encoded in those formats
or maybe data encoded in formats.
>
> The content rules might be replaced by a blanket clause:
> "Agencies and their employees and agents must ensure electronic
information is developed and maintained such that any receiving party
can use software to access that information in a manner which complies
with the software provisions."
>
> Sean Hayes
> Incubation Lab
> Accessibility Business Unit
> Microsoft
>
> Office: +44 118 909 5867,
> Mobile: +44 7875 091385
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim
> Tobias
> Sent: 22 September 2007 13:13
> To: 'TEITAC Web/Software Subcommittee'
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Thanks.
>
> The first numbers you cite -- are those the 8.1 and 8.2 provisions?
So "1"
> is actually 8.1-A in the September 14 draft?
>
> If that's the case, I still argue that although in a perfect world
> only the final product should need evaluation, we are so far from that

> perfect world that upstream provisions are still necessary. At the
> agency level they prevent mischief during use, and at the industry
> level they support the development and marketing of better tools. I
> don't see how they're overly burdensome to either party. For example,

> we're not insisting that agencies purchase tools that use the *most*
> accessible formats, nor are we imposing oversight on format
development itself.
>
> If there were no lead paint, there would be no lead painted toys.
>
> ***
> Jim Tobias
> Inclusive Technologies
> +1.732.441.0831 v/tty
> +1.908.907.2387 mobile
> skype jimtobias
>
>
>
>> -----Original Message-----
>> From: Sean Hayes [mailto: = EMAIL ADDRESS REMOVED = ]
>> Sent: Saturday, September 22, 2007 7:53 AM
>> To: TEITAC Web/Software Subcommittee
>> Subject: Re: [teitac-websoftware] intro for 8.1?
>>
>> 1 - covered by 3C
>>
>> 2 - covered by 6 A,B&C
>>
>> 4 - covered by 3K
>>
>> 5,6 & 7 - covered by 3N
>>
>> 8 - covered by 3M
>>
>> 9 - covered by 3C
>>
>> 10 - covered by a combination of 3N and 3C.
>>
>> Sean Hayes
>> Incubation Lab
>> Accessibility Business Unit
>> Microsoft
>>
>> Office: +44 118 909 5867,
>> Mobile: +44 7875 091385
>>
>>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim
>> Tobias
>> Sent: 22 September 2007 12:42
>> To: 'TEITAC Web/Software Subcommittee'
>> Subject: Re: [teitac-websoftware] intro for 8.1?
>>
>> Sorry -- can you point to the specific provision(s) that would have
>> the effect you claim? I'm not seeing it.
>>
>> ***
>> Jim Tobias
>> Inclusive Technologies
>> +1.732.441.0831 v/tty
>> +1.908.907.2387 mobile
>> skype jimtobias
>>
>>
>>

From: Sean Hayes
Date: Mon, Sep 24 2007 9:55 AM
Subject: Re: intro for 8.1?

No the situation is not the same. Typically AT does not access content formats directly (although this might be the case for example for Braille encoded ASCII), it is typically mediated through an software application.

Sean Hayes
Incubation Lab
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,
Mobile: +44 7875 091385


-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg Vanderheiden
Sent: 24 September 2007 16:39
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] intro for 8.1?

This is similar to the "accessibility supported" concept in WCAG.

In WCAG however the technologies must actually be supported by at least some
AT.

In 508 as written - (as I understand it) all that is required is that there
be an API for the format to pass 508. There does not have to be any AT that
actually works with the Format.

1) do I understand this correctly?
2) do we want to rewrite slightly so that there has to be actual AT that
works with the format?

If I misunderstood and AT is required we should put a statement somewhere to
make it clear since it is ambiguous and some feel that AT is not required.

thanks


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



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Hoffman, Allen
> Sent: Monday, September 24, 2007 7:16 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Procurement applies to information and data.
> information and data are delivered in some format.
>
> So, for example, I buy a credit reporting service which
> provides daily reports in IDF (inaccessible document format),
> and another vendor offers that information in (adf),
> accessible document format. Now, you might infer section 3
> applies, but almost nobody will in the acquisition side of
> things. Without this being an explicitly described item it
> will, and has gotten lost and overlooked.
>
> I think there certainly may be some scoping tweaking that
> would help, but as one who as strived desperately over the
> past many years to improve the accessibility of content,
> delivered by various software mechanisms, I can say this link
> is what is missing and sorely requires some strong mechanism
> to fix it. Much of the Access-Board's initial question of
> how does Section 508 apply to "content" is based around
> exactly this problem in the end. We have addressed the
> problem only in the surface fashion if we leave out the
> format portion, and history demonstrates that that approach
> doesn't work. if there is an interim mechanism we can use
> I'd be all for exploring it.
>
>
>
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Sean Hayes
> Sent: Monday, September 24, 2007 5:25 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Peter, I think your observations are valid in the context of
> office documents, but when we examine the wider scope of what
> the term "content format" covers I think we find problems.
>
> It might be a valid tactic for an agency trying to meet 508
> to voluntarily reduce their complexity burden by
> standardising on a specific set of technologies like OS, AT
> and office document types, however as you say that is out of
> the scope of 508. And even if so the agency would still need
> to be able to interoperate with content and systems outside
> of their control, as well as ensuring that the content which
> is created actually uses the accessibility features.
>
> I agree that the group has done some good work on identifying
> the kind of information software needs to be able to obtain
> when using a content format in order to meet the operational
> provisions, but as I have already stated, it is not always
> appropriate to include that information directly in the
> content itself.
>
> I'm not necessarily against recording the groups guidance
> somewhere but I think there are a number of problems with
> recording it as specific provisions within 508.
>
> For one, there is the harmonisation problem, no other
> international standard has such provisions (possibly for the
> reasons I outline below), and that procurement applies to
> software and not content formats.
>
> Then there is the issue that federal agencies between them
> record terabytes of information each year, including digital
> photographs; satellite imagery; cctv traffic, security, and
> other video; medical scans; geographical information and so
> on. These are all recorded in content formats which would not
> meet the proposed provisions on their own. Even if the
> agencies could employ the armies of operators it would
> require to create the descriptions, captions and annotations
> to make this information accessible; for practical, legal and
> forensic reasons, any such additional information would
> likely be entered into a media management database of some
> sort, not by altering the original content formats.
>
> The proposed content rules while applicable in some specific
> cases, such as office document creation, do not encompass
> situations where the information is distributed over a set of
> content formats, such as HTML and PNG, or DV and timed text
> files. They also do not accommodate situations where data
> must necessarily live in an inaccessible format for some
> period and would be made accessible by later processing, like
> capturing a digital photograph.
>
> So since the content provisions are already captured in a
> more general way by the provisions on software, and do not
> create the same operational constraints, I think we might be
> able to move the proposed content provisions into notes or
> guidance materials for the specific software provisions they
> relate to.
>
> We also need to think about how the software rules apply to
> tools which are used in the conversion of inaccessible
> recorded media such as photographs and video, we may need to
> craft some specific exceptions otherwise we may inadvertently
> prevent the agencies from procuring tools such as Photoshop
> which are commonly used in the process of making such
> materials accessible.
>
> Sean Hayes
> Incubation Lab
> Accessibility Business Unit
> Microsoft
>
> Office: +44 118 909 5867,
> Mobile: +44 7875 091385
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Peter Korn
> Sent: 22 September 2007 17:37
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Hi Sean,
>
> I think it is true that today few if any U.S. Federal
> Government agencies "procure" formats. But we have certainly
> seen several U.S.
> States looking to formally standardize on document formats (cf.
> Massachusetts). Likewise we have seen this in a number of
> European countries. And I believe the U.S. Library of
> Congress and other archiving organizations have been looking
> at like standardization.
>
> As standardization is different from procurement, it may be
> that the vehicle of Section 508 is not the right vehicle for
> this. But it seems clear to me that an enumeration of the
> accessibility information that must be "preservable" in/with
> a document format is an entirely appropriate thing to write
> down, so that organizations that are looking to standardize
> on some number of document formats know what they must look
> for to ensure accessibility information is preservable in that format.
>
> And I think this subcommittee has done a very nice job of
> doing that in this collection of provisions.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
> > Sorry, I was working from the Sept 3 draft.
> >
> > One logical problem, if the primary leverage applied by agencies is
> procurement, is that the agency does not typically procure
> formats. It procures tools that generate and consume data
> encoded in those formats or maybe data encoded in formats.
> >
> > The content rules might be replaced by a blanket clause:
> > "Agencies and their employees and agents must ensure electronic
> information is developed and maintained such that any
> receiving party can use software to access that information
> in a manner which complies with the software provisions."
> >
> > Sean Hayes
> > Incubation Lab
> > Accessibility Business Unit
> > Microsoft
> >
> > Office: +44 118 909 5867,
> > Mobile: +44 7875 091385
> >
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> > Tobias
> > Sent: 22 September 2007 13:13
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > Thanks.
> >
> > The first numbers you cite -- are those the 8.1 and 8.2 provisions?
> So "1"
> > is actually 8.1-A in the September 14 draft?
> >
> > If that's the case, I still argue that although in a perfect world
> > only the final product should need evaluation, we are so
> far from that
>
> > perfect world that upstream provisions are still necessary. At the
> > agency level they prevent mischief during use, and at the industry
> > level they support the development and marketing of better
> tools. I
> > don't see how they're overly burdensome to either party.
> For example,
>
> > we're not insisting that agencies purchase tools that use
> the *most*
> > accessible formats, nor are we imposing oversight on format
> development itself.
> >
> > If there were no lead paint, there would be no lead painted toys.
> >
> > ***
> > Jim Tobias
> > Inclusive Technologies
> > +1.732.441.0831 v/tty
> > +1.908.907.2387 mobile
> > skype jimtobias
> >
> >
> >
> >> -----Original Message-----
> >> From: Sean Hayes [mailto: = EMAIL ADDRESS REMOVED = ]
> >> Sent: Saturday, September 22, 2007 7:53 AM
> >> To: TEITAC Web/Software Subcommittee
> >> Subject: Re: [teitac-websoftware] intro for 8.1?
> >>
> >> 1 - covered by 3C
> >>
> >> 2 - covered by 6 A,B&C
> >>
> >> 4 - covered by 3K
> >>
> >> 5,6 & 7 - covered by 3N
> >>
> >> 8 - covered by 3M
> >>
> >> 9 - covered by 3C
> >>
> >> 10 - covered by a combination of 3N and 3C.
> >>
> >> Sean Hayes
> >> Incubation Lab
> >> Accessibility Business Unit
> >> Microsoft
> >>
> >> Office: +44 118 909 5867,
> >> Mobile: +44 7875 091385
> >>
> >>
> >> -----Original Message-----
> >> From: = EMAIL ADDRESS REMOVED =
> >> [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> >> Tobias
> >> Sent: 22 September 2007 12:42
> >> To: 'TEITAC Web/Software Subcommittee'
> >> Subject: Re: [teitac-websoftware] intro for 8.1?
> >>
> >> Sorry -- can you point to the specific provision(s) that
> would have
> >> the effect you claim? I'm not seeing it.
> >>
> >> ***
> >> Jim Tobias
> >> Inclusive Technologies
> >> +1.732.441.0831 v/tty
> >> +1.908.907.2387 mobile
> >> skype jimtobias
> >>
> >>
> >>

From: Andrew Kirkpatrick
Date: Mon, Sep 24 2007 10:00 AM
Subject: Re: intro for 8.1?

> So, for example, I buy a credit reporting service which
> provides daily reports in IDF (inaccessible document format),
> and another vendor offers that information in (adf),
> accessible document format. Now, you might infer section 3
> applies, but almost nobody will in the acquisition side of
> things. Without this being an explicitly described item it
> will, and has gotten lost and overlooked.

Whoa. So you're saying that no one will evaluate the reports that are
generated in IDF or ADF based on Section 3? Are you suggesting that
they won't be evaluated at all or that the messaging to the procurement
people related to what sections apply to what kind of products? In my
view, of course they will and should be evaluated in Section 3, that's
where we've put the requirements that the reports need to meet!

> Much of the Access-Board's initial question of
> how does Section 508 apply to "content" is based around
> exactly this problem in the end.

The questions of "content" being accessible has to do with people not
knowing where to evaluate specific types of or aspects of products.
Creating a content format requirements section isn't going to solve this
concern - if I have a web-based tool that creates PDF files and emails
them in HTML format emails to other users, I need to know where to
evaluate the different aspects of my application. If I look and
determine that the PDF format can support everything that is specified
in section 8, am I any closer to verifying that the PDF and HTML output
from my app meet section 508? Not a bit. I can't assume that my output
meets section 3 without going and checking that the rules of my
application create compliant output.

AWK

From: Andrew Kirkpatrick
Date: Mon, Sep 24 2007 10:05 AM
Subject: Re: intro for 8.1?

Thanks Sean -- I agree that providing these as notes retains their value
within the context of the product being evaluated.
AWK

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Sean Hayes
> Sent: Monday, September 24, 2007 11:48 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Allen, I agree with you on the need. What I'm having a
> problem with is the proposed solution.
>
> In addition to the problems I've already outlined, Just
> because a vendor offers information in a format adf, does not
> mean the vendor has filled in the blanks correctly so that
> the purchased information is in fact accessible.
>
> If a vendor offers the "news in pictures" as a set of JPEG's
> and provides text equivalents as an HTML file with links to
> the images containing the alt text, is he prevented from
> selling the JPEG's to a federal agency? The current rules
> would say yes (assuming we interpret them to mean
> "information encoded in a content format", rather than
> "content format").
>
> My proposal was to move the current content format proposals
> into notes on the software provisions, to keep the discussion
> concrete, here is what it might look like for 'Non-text Objects':
>
> 3-F - Non-text Objects
> Non-text Objects: All non-text objects that are presented to
> the user must have a text alternative that presents
> equivalent information, except for the situations listed below.
> Note: In order to achieve this provision, such non text
> objects in data operated on by the software must be
> associated with equivalent textual descriptions that the
> software can obtain as readily as it can obtain the non-text
> object itself.
>
> Sean Hayes
> Incubation Lab
> Accessibility Business Unit
> Microsoft
>
> Office: +44 118 909 5867,
> Mobile: +44 7875 091385
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Hoffman, Allen
> Sent: 24 September 2007 13:16
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Procurement applies to information and data.
> information and data are delivered in some format.
>
> So, for example, I buy a credit reporting service which
> provides daily reports in IDF (inaccessible document format),
> and another vendor offers that information in (adf),
> accessible document format. Now, you might infer section 3
> applies, but almost nobody will in the acquisition side of
> things. Without this being an explicitly described item it
> will, and has gotten lost and overlooked.
>
> I think there certainly may be some scoping tweaking that
> would help, but as one who as strived desperately over the
> past many years to improve the accessibility of content,
> delivered by various software mechanisms, I can say this link
> is what is missing and sorely requires some strong mechanism
> to fix it. Much of the Access-Board's initial question of
> how does Section 508 apply to "content" is based around
> exactly this problem in the end. We have addressed the
> problem only in the surface fashion if we leave out the
> format portion, and history demonstrates that that approach
> doesn't work. if there is an interim mechanism we can use
> I'd be all for exploring it.
>
>
>
>
>
>
> Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Sean Hayes
> Sent: Monday, September 24, 2007 5:25 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Peter, I think your observations are valid in the context of
> office documents, but when we examine the wider scope of what
> the term "content format" covers I think we find problems.
>
> It might be a valid tactic for an agency trying to meet 508
> to voluntarily reduce their complexity burden by
> standardising on a specific set of technologies like OS, AT
> and office document types, however as you say that is out of
> the scope of 508. And even if so the agency would still need
> to be able to interoperate with content and systems outside
> of their control, as well as ensuring that the content which
> is created actually uses the accessibility features.
>
> I agree that the group has done some good work on identifying
> the kind of information software needs to be able to obtain
> when using a content format in order to meet the operational
> provisions, but as I have already stated, it is not always
> appropriate to include that information directly in the
> content itself.
>
> I'm not necessarily against recording the groups guidance
> somewhere but I think there are a number of problems with
> recording it as specific provisions within 508.
>
> For one, there is the harmonisation problem, no other
> international standard has such provisions (possibly for the
> reasons I outline below), and that procurement applies to
> software and not content formats.
>
> Then there is the issue that federal agencies between them
> record terabytes of information each year, including digital
> photographs; satellite imagery; cctv traffic, security, and
> other video; medical scans; geographical information and so
> on. These are all recorded in content formats which would not
> meet the proposed provisions on their own. Even if the
> agencies could employ the armies of operators it would
> require to create the descriptions, captions and annotations
> to make this information accessible; for practical, legal and
> forensic reasons, any such additional information would
> likely be entered into a media management database of some
> sort, not by altering the original content formats.
>
> The proposed content rules while applicable in some specific
> cases, such as office document creation, do not encompass
> situations where the information is distributed over a set of
> content formats, such as HTML and PNG, or DV and timed text
> files. They also do not accommodate situations where data
> must necessarily live in an inaccessible format for some
> period and would be made accessible by later processing, like
> capturing a digital photograph.
>
> So since the content provisions are already captured in a
> more general way by the provisions on software, and do not
> create the same operational constraints, I think we might be
> able to move the proposed content provisions into notes or
> guidance materials for the specific software provisions they
> relate to.
>
> We also need to think about how the software rules apply to
> tools which are used in the conversion of inaccessible
> recorded media such as photographs and video, we may need to
> craft some specific exceptions otherwise we may inadvertently
> prevent the agencies from procuring tools such as Photoshop
> which are commonly used in the process of making such
> materials accessible.
>
> Sean Hayes
> Incubation Lab
> Accessibility Business Unit
> Microsoft
>
> Office: +44 118 909 5867,
> Mobile: +44 7875 091385
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Peter Korn
> Sent: 22 September 2007 17:37
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> Hi Sean,
>
> I think it is true that today few if any U.S. Federal
> Government agencies "procure" formats. But we have certainly
> seen several U.S.
> States looking to formally standardize on document formats (cf.
> Massachusetts). Likewise we have seen this in a number of
> European countries. And I believe the U.S. Library of
> Congress and other archiving organizations have been looking
> at like standardization.
>
> As standardization is different from procurement, it may be
> that the vehicle of Section 508 is not the right vehicle for
> this. But it seems clear to me that an enumeration of the
> accessibility information that must be "preservable" in/with
> a document format is an entirely appropriate thing to write
> down, so that organizations that are looking to standardize
> on some number of document formats know what they must look
> for to ensure accessibility information is preservable in that format.
>
> And I think this subcommittee has done a very nice job of
> doing that in this collection of provisions.
>
>
> Regards,
>
> Peter Korn
> Accessibility Architect,
> Sun Microsystems, Inc.
>
> > Sorry, I was working from the Sept 3 draft.
> >
> > One logical problem, if the primary leverage applied by agencies is
> procurement, is that the agency does not typically procure
> formats. It procures tools that generate and consume data
> encoded in those formats or maybe data encoded in formats.
> >
> > The content rules might be replaced by a blanket clause:
> > "Agencies and their employees and agents must ensure electronic
> information is developed and maintained such that any
> receiving party can use software to access that information
> in a manner which complies with the software provisions."
> >
> > Sean Hayes
> > Incubation Lab
> > Accessibility Business Unit
> > Microsoft
> >
> > Office: +44 118 909 5867,
> > Mobile: +44 7875 091385
> >
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> > Tobias
> > Sent: 22 September 2007 13:13
> > To: 'TEITAC Web/Software Subcommittee'
> > Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> > Thanks.
> >
> > The first numbers you cite -- are those the 8.1 and 8.2 provisions?
> So "1"
> > is actually 8.1-A in the September 14 draft?
> >
> > If that's the case, I still argue that although in a perfect world
> > only the final product should need evaluation, we are so
> far from that
>
> > perfect world that upstream provisions are still necessary. At the
> > agency level they prevent mischief during use, and at the industry
> > level they support the development and marketing of better
> tools. I
> > don't see how they're overly burdensome to either party.
> For example,
>
> > we're not insisting that agencies purchase tools that use
> the *most*
> > accessible formats, nor are we imposing oversight on format
> development itself.
> >
> > If there were no lead paint, there would be no lead painted toys.
> >
> > ***
> > Jim Tobias
> > Inclusive Technologies
> > +1.732.441.0831 v/tty
> > +1.908.907.2387 mobile
> > skype jimtobias
> >
> >
> >
> >> -----Original Message-----
> >> From: Sean Hayes [mailto: = EMAIL ADDRESS REMOVED = ]
> >> Sent: Saturday, September 22, 2007 7:53 AM
> >> To: TEITAC Web/Software Subcommittee
> >> Subject: Re: [teitac-websoftware] intro for 8.1?
> >>
> >> 1 - covered by 3C
> >>
> >> 2 - covered by 6 A,B&C
> >>
> >> 4 - covered by 3K
> >>
> >> 5,6 & 7 - covered by 3N
> >>
> >> 8 - covered by 3M
> >>
> >> 9 - covered by 3C
> >>
> >> 10 - covered by a combination of 3N and 3C.
> >>
> >> Sean Hayes
> >> Incubation Lab
> >> Accessibility Business Unit
> >> Microsoft
> >>
> >> Office: +44 118 909 5867,
> >> Mobile: +44 7875 091385
> >>
> >>
> >> -----Original Message-----
> >> From: = EMAIL ADDRESS REMOVED =
> >> [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> >> Tobias
> >> Sent: 22 September 2007 12:42
> >> To: 'TEITAC Web/Software Subcommittee'
> >> Subject: Re: [teitac-websoftware] intro for 8.1?
> >>
> >> Sorry -- can you point to the specific provision(s) that
> would have
> >> the effect you claim? I'm not seeing it.
> >>
> >> ***
> >> Jim Tobias
> >> Inclusive Technologies
> >> +1.732.441.0831 v/tty
> >> +1.908.907.2387 mobile
> >> skype jimtobias
> >>
> >>
> >>

From: Katie Haritos-Shea
Date: Tue, Sep 25 2007 9:00 AM
Subject: Re: intro for 8.1?

I Strongly agree with Allen

Katie

-----Original Message-----
>From: "Hoffman, Allen" < = EMAIL ADDRESS REMOVED = >
>Sent: Sep 24, 2007 8:15 AM
>To: TEITAC Web/Software Subcommittee < = EMAIL ADDRESS REMOVED = >
>Subject: Re: [teitac-websoftware] intro for 8.1?
>
>Procurement applies to information and data.
>information and data are delivered in some format.
>
>So, for example, I buy a credit reporting service which provides daily
>reports in IDF (inaccessible document format), and another vendor offers
>that information in (adf), accessible document format. Now, you might
>infer section 3 applies, but almost nobody will in the acquisition side
>of things. Without this being an explicitly described item it will, and
>has gotten lost and overlooked.
>
>I think there certainly may be some scoping tweaking that would help,
>but as one who as strived desperately over the past many years to
>improve the accessibility of content, delivered by various software
>mechanisms, I can say this link is what is missing and sorely requires
>some strong mechanism to fix it. Much of the Access-Board's initial
>question of how does Section 508 apply to "content" is based around
>exactly this problem in the end. We have addressed the problem only in
>the surface fashion if we leave out the format portion, and history
>demonstrates that that approach doesn't work. if there is an interim
>mechanism we can use I'd be all for exploring it.
>
>
>
>
>
>
>Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
>
>-----Original Message-----
>From: = EMAIL ADDRESS REMOVED =
>[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Sean
>Hayes
>Sent: Monday, September 24, 2007 5:25 AM
>To: TEITAC Web/Software Subcommittee
>Subject: Re: [teitac-websoftware] intro for 8.1?
>
>Peter, I think your observations are valid in the context of office
>documents, but when we examine the wider scope of what the term "content
>format" covers I think we find problems.
>
>It might be a valid tactic for an agency trying to meet 508 to
>voluntarily reduce their complexity burden by standardising on a
>specific set of technologies like OS, AT and office document types,
>however as you say that is out of the scope of 508. And even if so the
>agency would still need to be able to interoperate with content and
>systems outside of their control, as well as ensuring that the content
>which is created actually uses the accessibility features.
>
>I agree that the group has done some good work on identifying the kind
>of information software needs to be able to obtain when using a content
>format in order to meet the operational provisions, but as I have
>already stated, it is not always appropriate to include that information
>directly in the content itself.
>
>I'm not necessarily against recording the groups guidance somewhere but
>I think there are a number of problems with recording it as specific
>provisions within 508.
>
>For one, there is the harmonisation problem, no other international
>standard has such provisions (possibly for the reasons I outline below),
>and that procurement applies to software and not content formats.
>
>Then there is the issue that federal agencies between them record
>terabytes of information each year, including digital photographs;
>satellite imagery; cctv traffic, security, and other video; medical
>scans; geographical information and so on. These are all recorded in
>content formats which would not meet the proposed provisions on their
>own. Even if the agencies could employ the armies of operators it would
>require to create the descriptions, captions and annotations to make
>this information accessible; for practical, legal and forensic reasons,
>any such additional information would likely be entered into a media
>management database of some sort, not by altering the original content
>formats.
>
>The proposed content rules while applicable in some specific cases, such
>as office document creation, do not encompass situations where the
>information is distributed over a set of content formats, such as HTML
>and PNG, or DV and timed text files. They also do not accommodate
>situations where data must necessarily live in an inaccessible format
>for some period and would be made accessible by later processing, like
>capturing a digital photograph.
>
>So since the content provisions are already captured in a more general
>way by the provisions on software, and do not create the same
>operational constraints, I think we might be able to move the proposed
>content provisions into notes or guidance materials for the specific
>software provisions they relate to.
>
>We also need to think about how the software rules apply to tools which
>are used in the conversion of inaccessible recorded media such as
>photographs and video, we may need to craft some specific exceptions
>otherwise we may inadvertently prevent the agencies from procuring tools
>such as Photoshop which are commonly used in the process of making such
>materials accessible.
>
>Sean Hayes
>Incubation Lab
>Accessibility Business Unit
>Microsoft
>
>Office: +44 118 909 5867,
>Mobile: +44 7875 091385
>
>
>-----Original Message-----
>From: = EMAIL ADDRESS REMOVED =
>[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter
>Korn
>Sent: 22 September 2007 17:37
>To: TEITAC Web/Software Subcommittee
>Subject: Re: [teitac-websoftware] intro for 8.1?
>
>Hi Sean,
>
>I think it is true that today few if any U.S. Federal Government
>agencies "procure" formats. But we have certainly seen several U.S.
>States looking to formally standardize on document formats (cf.
>Massachusetts). Likewise we have seen this in a number of European
>countries. And I believe the U.S. Library of Congress and other
>archiving organizations have been looking at like standardization.
>
>As standardization is different from procurement, it may be that the
>vehicle of Section 508 is not the right vehicle for this. But it seems
>clear to me that an enumeration of the accessibility information that
>must be "preservable" in/with a document format is an entirely
>appropriate thing to write down, so that organizations that are looking
>to standardize on some number of document formats know what they must
>look for to ensure accessibility information is preservable in that
>format.
>
>And I think this subcommittee has done a very nice job of doing that in
>this collection of provisions.
>
>
>Regards,
>
>Peter Korn
>Accessibility Architect,
>Sun Microsystems, Inc.
>
>> Sorry, I was working from the Sept 3 draft.
>>
>> One logical problem, if the primary leverage applied by agencies is
>procurement, is that the agency does not typically procure formats. It
>procures tools that generate and consume data encoded in those formats
>or maybe data encoded in formats.
>>
>> The content rules might be replaced by a blanket clause:
>> "Agencies and their employees and agents must ensure electronic
>information is developed and maintained such that any receiving party
>can use software to access that information in a manner which complies
>with the software provisions."
>>
>> Sean Hayes
>> Incubation Lab
>> Accessibility Business Unit
>> Microsoft
>>
>> Office: +44 118 909 5867,
>> Mobile: +44 7875 091385
>>
>>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim
>> Tobias
>> Sent: 22 September 2007 13:13
>> To: 'TEITAC Web/Software Subcommittee'
>> Subject: Re: [teitac-websoftware] intro for 8.1?
>>
>> Thanks.
>>
>> The first numbers you cite -- are those the 8.1 and 8.2 provisions?
>So "1"
>> is actually 8.1-A in the September 14 draft?
>>
>> If that's the case, I still argue that although in a perfect world
>> only the final product should need evaluation, we are so far from that
>
>> perfect world that upstream provisions are still necessary. At the
>> agency level they prevent mischief during use, and at the industry
>> level they support the development and marketing of better tools. I
>> don't see how they're overly burdensome to either party. For example,
>
>> we're not insisting that agencies purchase tools that use the *most*
>> accessible formats, nor are we imposing oversight on format
>development itself.
>>
>> If there were no lead paint, there would be no lead painted toys.
>>
>> ***
>> Jim Tobias
>> Inclusive Technologies
>> +1.732.441.0831 v/tty
>> +1.908.907.2387 mobile
>> skype jimtobias
>>
>>
>>
>>> -----Original Message-----
>>> From: Sean Hayes [mailto: = EMAIL ADDRESS REMOVED = ]
>>> Sent: Saturday, September 22, 2007 7:53 AM
>>> To: TEITAC Web/Software Subcommittee
>>> Subject: Re: [teitac-websoftware] intro for 8.1?
>>>
>>> 1 - covered by 3C
>>>
>>> 2 - covered by 6 A,B&C
>>>
>>> 4 - covered by 3K
>>>
>>> 5,6 & 7 - covered by 3N
>>>
>>> 8 - covered by 3M
>>>
>>> 9 - covered by 3C
>>>
>>> 10 - covered by a combination of 3N and 3C.
>>>
>>> Sean Hayes
>>> Incubation Lab
>>> Accessibility Business Unit
>>> Microsoft
>>>
>>> Office: +44 118 909 5867,
>>> Mobile: +44 7875 091385
>>>
>>>
>>> -----Original Message-----
>>> From: = EMAIL ADDRESS REMOVED =
>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim
>>> Tobias
>>> Sent: 22 September 2007 12:42
>>> To: 'TEITAC Web/Software Subcommittee'
>>> Subject: Re: [teitac-websoftware] intro for 8.1?
>>>
>>> Sorry -- can you point to the specific provision(s) that would have
>>> the effect you claim? I'm not seeing it.
>>>
>>> ***
>>> Jim Tobias
>>> Inclusive Technologies
>>> +1.732.441.0831 v/tty
>>> +1.908.907.2387 mobile
>>> skype jimtobias
>>>
>>>
>>>

From: Andrew Kirkpatrick
Date: Tue, Sep 25 2007 9:35 AM
Subject: Re: intro for 8.1?

What I don't understand is why we might assume that the report that
Allen refers to below (a report from a credit reporting service)
wouldn't be evaluated under section 3, "User interfaces and electronic
content". Of course it will be evaluated under section 3 - that's the
only place to evaluate it. Section 8 doesn't apply to the report
document, except insofar that the report uses a content format, which is
undeniably insufficient to declare whether the report is compliant by
itself.

Katie, are you agreeing that the report mentioned would not be evaluated
under section 3 or something else?

AWK

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Katie Haritos-Shea
> Sent: Tuesday, September 25, 2007 10:59 AM
> To: TEITAC Web/Software Subcommittee; TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] intro for 8.1?
>
> I Strongly agree with Allen
>
> Katie
>
> -----Original Message-----
> >From: "Hoffman, Allen" < = EMAIL ADDRESS REMOVED = >
> >Sent: Sep 24, 2007 8:15 AM
> >To: TEITAC Web/Software Subcommittee
> >< = EMAIL ADDRESS REMOVED = >
> >Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> >Procurement applies to information and data.
> >information and data are delivered in some format.
> >
> >So, for example, I buy a credit reporting service which
> provides daily
> >reports in IDF (inaccessible document format), and another vendor
> >offers that information in (adf), accessible document
> format. Now, you
> >might infer section 3 applies, but almost nobody will in the
> >acquisition side of things. Without this being an
> explicitly described
> >item it will, and has gotten lost and overlooked.
> >
> >I think there certainly may be some scoping tweaking that
> would help,
> >but as one who as strived desperately over the past many years to
> >improve the accessibility of content, delivered by various software
> >mechanisms, I can say this link is what is missing and
> sorely requires
> >some strong mechanism to fix it. Much of the Access-Board's initial
> >question of how does Section 508 apply to "content" is based around
> >exactly this problem in the end. We have addressed the
> problem only in
> >the surface fashion if we leave out the format portion, and history
> >demonstrates that that approach doesn't work. if there is
> an interim
> >mechanism we can use I'd be all for exploring it.
> >
> >
> >
> >
> >
> >
> >Allen Hoffman -- = EMAIL ADDRESS REMOVED = ; v: 202-447-0303
> >
> >-----Original Message-----
> >From: = EMAIL ADDRESS REMOVED =
> >[mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Sean
> >Hayes
> >Sent: Monday, September 24, 2007 5:25 AM
> >To: TEITAC Web/Software Subcommittee
> >Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> >Peter, I think your observations are valid in the context of office
> >documents, but when we examine the wider scope of what the term
> >"content format" covers I think we find problems.
> >
> >It might be a valid tactic for an agency trying to meet 508 to
> >voluntarily reduce their complexity burden by standardising on a
> >specific set of technologies like OS, AT and office document types,
> >however as you say that is out of the scope of 508. And even
> if so the
> >agency would still need to be able to interoperate with content and
> >systems outside of their control, as well as ensuring that
> the content
> >which is created actually uses the accessibility features.
> >
> >I agree that the group has done some good work on
> identifying the kind
> >of information software needs to be able to obtain when
> using a content
> >format in order to meet the operational provisions, but as I have
> >already stated, it is not always appropriate to include that
> >information directly in the content itself.
> >
> >I'm not necessarily against recording the groups guidance
> somewhere but
> >I think there are a number of problems with recording it as specific
> >provisions within 508.
> >
> >For one, there is the harmonisation problem, no other international
> >standard has such provisions (possibly for the reasons I outline
> >below), and that procurement applies to software and not
> content formats.
> >
> >Then there is the issue that federal agencies between them record
> >terabytes of information each year, including digital photographs;
> >satellite imagery; cctv traffic, security, and other video; medical
> >scans; geographical information and so on. These are all recorded in
> >content formats which would not meet the proposed provisions
> on their
> >own. Even if the agencies could employ the armies of
> operators it would
> >require to create the descriptions, captions and annotations to make
> >this information accessible; for practical, legal and
> forensic reasons,
> >any such additional information would likely be entered into a media
> >management database of some sort, not by altering the
> original content
> >formats.
> >
> >The proposed content rules while applicable in some specific cases,
> >such as office document creation, do not encompass
> situations where the
> >information is distributed over a set of content formats,
> such as HTML
> >and PNG, or DV and timed text files. They also do not accommodate
> >situations where data must necessarily live in an
> inaccessible format
> >for some period and would be made accessible by later
> processing, like
> >capturing a digital photograph.
> >
> >So since the content provisions are already captured in a
> more general
> >way by the provisions on software, and do not create the same
> >operational constraints, I think we might be able to move
> the proposed
> >content provisions into notes or guidance materials for the specific
> >software provisions they relate to.
> >
> >We also need to think about how the software rules apply to
> tools which
> >are used in the conversion of inaccessible recorded media such as
> >photographs and video, we may need to craft some specific exceptions
> >otherwise we may inadvertently prevent the agencies from procuring
> >tools such as Photoshop which are commonly used in the process of
> >making such materials accessible.
> >
> >Sean Hayes
> >Incubation Lab
> >Accessibility Business Unit
> >Microsoft
> >
> >Office: +44 118 909 5867,
> >Mobile: +44 7875 091385
> >
> >
> >-----Original Message-----
> >From: = EMAIL ADDRESS REMOVED =
> >[mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Peter
> >Korn
> >Sent: 22 September 2007 17:37
> >To: TEITAC Web/Software Subcommittee
> >Subject: Re: [teitac-websoftware] intro for 8.1?
> >
> >Hi Sean,
> >
> >I think it is true that today few if any U.S. Federal Government
> >agencies "procure" formats. But we have certainly seen several U.S.
> >States looking to formally standardize on document formats (cf.
> >Massachusetts). Likewise we have seen this in a number of European
> >countries. And I believe the U.S. Library of Congress and other
> >archiving organizations have been looking at like standardization.
> >
> >As standardization is different from procurement, it may be that the
> >vehicle of Section 508 is not the right vehicle for this.
> But it seems
> >clear to me that an enumeration of the accessibility
> information that
> >must be "preservable" in/with a document format is an entirely
> >appropriate thing to write down, so that organizations that
> are looking
> >to standardize on some number of document formats know what
> they must
> >look for to ensure accessibility information is preservable in that
> >format.
> >
> >And I think this subcommittee has done a very nice job of
> doing that in
> >this collection of provisions.
> >
> >
> >Regards,
> >
> >Peter Korn
> >Accessibility Architect,
> >Sun Microsystems, Inc.
> >
> >> Sorry, I was working from the Sept 3 draft.
> >>
> >> One logical problem, if the primary leverage applied by agencies is
> >procurement, is that the agency does not typically procure
> formats. It
> >procures tools that generate and consume data encoded in
> those formats
> >or maybe data encoded in formats.
> >>
> >> The content rules might be replaced by a blanket clause:
> >> "Agencies and their employees and agents must ensure electronic
> >information is developed and maintained such that any
> receiving party
> >can use software to access that information in a manner
> which complies
> >with the software provisions."
> >>
> >> Sean Hayes
> >> Incubation Lab
> >> Accessibility Business Unit
> >> Microsoft
> >>
> >> Office: +44 118 909 5867,
> >> Mobile: +44 7875 091385
> >>
> >>
> >> -----Original Message-----
> >> From: = EMAIL ADDRESS REMOVED =
> >> [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> >> Tobias
> >> Sent: 22 September 2007 13:13
> >> To: 'TEITAC Web/Software Subcommittee'
> >> Subject: Re: [teitac-websoftware] intro for 8.1?
> >>
> >> Thanks.
> >>
> >> The first numbers you cite -- are those the 8.1 and 8.2 provisions?
> >So "1"
> >> is actually 8.1-A in the September 14 draft?
> >>
> >> If that's the case, I still argue that although in a perfect world
> >> only the final product should need evaluation, we are so far from
> >> that
> >
> >> perfect world that upstream provisions are still
> necessary. At the
> >> agency level they prevent mischief during use, and at the industry
> >> level they support the development and marketing of better
> tools. I
> >> don't see how they're overly burdensome to either party. For
> >> example,
> >
> >> we're not insisting that agencies purchase tools that use
> the *most*
> >> accessible formats, nor are we imposing oversight on format
> >development itself.
> >>
> >> If there were no lead paint, there would be no lead painted toys.
> >>
> >> ***
> >> Jim Tobias
> >> Inclusive Technologies
> >> +1.732.441.0831 v/tty
> >> +1.908.907.2387 mobile
> >> skype jimtobias
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Sean Hayes [mailto: = EMAIL ADDRESS REMOVED = ]
> >>> Sent: Saturday, September 22, 2007 7:53 AM
> >>> To: TEITAC Web/Software Subcommittee
> >>> Subject: Re: [teitac-websoftware] intro for 8.1?
> >>>
> >>> 1 - covered by 3C
> >>>
> >>> 2 - covered by 6 A,B&C
> >>>
> >>> 4 - covered by 3K
> >>>
> >>> 5,6 & 7 - covered by 3N
> >>>
> >>> 8 - covered by 3M
> >>>
> >>> 9 - covered by 3C
> >>>
> >>> 10 - covered by a combination of 3N and 3C.
> >>>
> >>> Sean Hayes
> >>> Incubation Lab
> >>> Accessibility Business Unit
> >>> Microsoft
> >>>
> >>> Office: +44 118 909 5867,
> >>> Mobile: +44 7875 091385
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: = EMAIL ADDRESS REMOVED =
> >>> [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> >>> Tobias
> >>> Sent: 22 September 2007 12:42
> >>> To: 'TEITAC Web/Software Subcommittee'
> >>> Subject: Re: [teitac-websoftware] intro for 8.1?
> >>>
> >>> Sorry -- can you point to the specific provision(s) that
> would have
> >>> the effect you claim? I'm not seeing it.
> >>>
> >>> ***
> >>> Jim Tobias
> >>> Inclusive Technologies
> >>> +1.732.441.0831 v/tty
> >>> +1.908.907.2387 mobile
> >>> skype jimtobias
> >>>
> >>>
> >>>