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: Andrew Kirkpatrick
Date: Tue, Sep 25 2007 9:35 AM


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


WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University
http://webaim.org/teitac/mailarchives/mail_message?id=7048&listid=3
webaim.org
crawl=CC-MAIN-2013-20
22769
application/http; msgtype=response
sha1:T76HYVA7KM6DD336V5MDTK4VRGFSLTTG
<urn:uuid:c4ce4ece-9cad-465e-93c9-56ebaea1f85c>
2013-05-21T20:18:59Z
184.106.203.86
sha1:CEE74PXWHAIMVONPZJLUVRYULPAXNQCD
<urn:uuid:96d86f6c-fd72-44a1-a457-ffa3528b2527>
http://webaim.org/teitac/mailarchives/mail_message?id=7048&listid=3
response
<urn:uuid:1c02f533-3da9-4c33-bbf9-1cfe1b477d1b>
robots: classic
hostname: ip-10-60-113-184.ec2.internal
software: Nutch 1.6 (CC)/CC WarcExport 1.0
isPartOf: CC-MAIN-2013-20
operator: CommonCrawl Admin
description: Wide crawl of the web with URLs provided by Blekko for Spring 2013
publisher: CommonCrawl
format: WARC File Format 1.0
conformsTo: http://bibnum.bnf.fr/WARC/WARC_ISO_28500_version1_latestdraft.pdf