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: Sean Hayes
Date: Fri, Sep 21 2007 10:00 AM

"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