Thread Subject: Re: intro for 8.1?

Note

This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.

From: Hoffman, Allen
Date: Fri, Sep 21 2007 12:05 PM

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.
> > > > >
> > > > >
> > > > >

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University