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: Sat, Sep 22 2007 5:40 AM

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

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