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: Jim Tobias
Date: Sat, Sep 22 2007 5:45 AM

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

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