Thread Subject: Email Attachments (was RE: "Content" in oursubcommittee)

Return to this mailing list's archives

From: Bailey Bruce
Date: Fri, Oct 27 2006 8:30 AM
Subject: Email Attachments (was RE: "Content" in oursubcommittee)

This is a very thorny issue. It informed the Communications Task Force
deliberate decision to *not* support attachments to Teitac list
messages. Some mail admins remove all attachments as a general
practice, some filter by file extension (actually counter-productive
IMHO), others actively scan. No attachments at all is strict, but it
certainly levels the playing field!

> -----Original Message-----
> From: Brett, Thomas F [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Friday, October 27, 2006 7:24 AM
> To: TEITAC Web/Software Subcommittee
> Cc: Baquis David ; Creagan Tim; Bailey Bruce; Capozzi David
> Subject: RE: [teitac-websoftware] "Content" in our subcommittee
>
>> If I remember correctly, they had gotten a lot of questions about
>> whether documents attached to email, like a Word file with an
>> image, was covered by 508 and if so, did they require some other
>> sort of technical solution.
>
> As one of the individuals that has presented this question to
> the Access Board, I'd like to say that email is becoming more
> and more of a vehicle in which information is gather and
> information is disseminated. Either as an attachment or
> embedded in the email, forms and data are transmitted thru
> email systems. People using assistive technology may not be
> able to access this information. In addition to Word files,
> which are not necessarily accessible, PDF, TIFF, JPG, GIF
> files are also transmitted via email.

From: Jim Tobias
Date: Sat, Oct 28 2006 5:50 AM
Subject: Re: "Content" in our subcommittee

Thanks for your answers, Andi and Peter.

I'm concerned that this subcommittee, which already has a huge membership
and mission, might be taking on too much to also deal with Content.
Especially when I hear the item almost as an afterthought: "We said we would
first review all of the existing provisions and then tackle content." I
know we don't want to create any more Subcommittees than we need, but we
also can't have Super-Subcommittees in which so much of the work is
centralized that it undercuts the whole idea of parcelling it out.

Here's a categorization scheme for the functions addressed by this
Subcommittee:

- Orientation: can a user discover what's in the app or on the page, and
what it's good for?
- Navigation: can a user get to all the controls and information ports?
- Operation: can a user manipulate the interface to deliver the intended
output or outcome?
- Content: can a user receive the intended output or outcome?

The first 3 are clearly within the 1194.21 and 1194.22 purview. But Content
may cross over into issues already under consideration by both the Telecom
and AV Subcommittees, and possibly others. Conversely, one of the Telecom
chairs has already raised a flag asking what to do about telecom software --
where does it fit? How do we want to answer that? I'm personally
comfortable welcoming all software issues, because they may be pretty
similar and may even live in the same external standard (as in HFES 200.4
for IVR, for example).

Whether or not TEITAC winds up using a more functional framework for the
Standards, we should keep it in the back of our minds, especially as the
workload of this subcommittee threatens to overload the ability of some
members to keep up and contribute.


***********
Jim Tobias
Inclusive Technologies
= EMAIL ADDRESS REMOVED =
+1.732.441.0831 v/tty
skype jimtobias
www.inclusive.com


> -----Original Message-----
> From: Andi Snow-Weaver [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Friday, October 27, 2006 8:13 AM
> To: TEITAC Web/Software Subcommittee
> Subject: Re: [teitac-websoftware] "Content" in our subcommittee
>
> Good discussion.
>
> Peter is right. We said we would first review all of the
> existing provisions and then tackle content. I expect we will
> encounter content issues as we discuss the exisitng software
> and Web provisions. Tom's posting had a good summary of
> e-mail issues. I have started a page on Content issues so
> that we can collect these as we go along.
>
> http://teitac.org/wiki/Web_and_Software:content
>
> Andi
>
>

From: Baquis David
Date: Mon, Oct 30 2006 2:55 PM
Subject: Re: "Content" in our subcommittee

The question of whether "a Word document attached to an email is
covered" does not sufficiently capture the breadth of what the Access
Board needs recommendations on. So let me try to lay it out:

Question #1: Is electronic content covered under 508?

Both the statute and the Standard say that Section 508 addresses
"information and data". What does that mean? It seems to suggest that
Section 508 does not just address technology. Do you think that any of
the current provisions in the 508 Standard cover content? Do you believe
that the web provisions are really "technology" provisions (as opposed
to content provisions) because the web is considered a piece of
technology and that is why it is covered? (Note that web is specifically
given as an example in the definition of E&IT). Do you think it is
confusion that what seems like content to some, can be viewed as
technology to others? Certainly, I think it can be clarified that we are
talking about electronic content, not just any content. So the Committee
needs to deliberate on the yes or no question of whether it was the
intention of the law to address accessibility of electronic content.

Related to that, we strongly need information on the potential economic
impact of such a determination. It is best if the Access Board is not
left on its own to try to figure this out after the Committee disbands,
as that might result in an overestimate. It is important that the
Committee understands that this economic impact information could make a
difference in whether this or any other recommendation makes it into the
final rule. Many advocates would like to see clear requirements
covering electronic content. Others outside the world of accessibility,
however, worry about whether it is "do-able" to impose such a
requirement on the huge volume of government electronic content.


2.) Question #2: If electronic content is covered under 508, then what
kind of information and data is covered?

* Some people have remarked that they think the current standards
are geared toward a specific type of code (HTML). What do you think and
do you have a recommendation related to whether they should go beyond
that?
* Does electronic content include various documents, such as PDF,
wordprocessed, spreadsheet, database, presentation shows, etc?
* Does electronic content include email? Does that mean both
web-based email as well as "regular" email (for lack of a better word).


3.) Question #3: Assuming that you determine that electronic content is
covered and you discern the types of information and data that are
covered, does it matter where the electronic content resides?

* Must the content reside on a website in order for 508 provisions
to apply to it?
* To ask that another way, if the content does not reside on a
website, does that mean that 508 does not require it to be accessible?
* What if a document resides on a server? Sometimes the server is
accessed via an office intranet, but does that matter to you in the
determination of whether it is covered under 508?
* What about FTP files?
* What if the document is on a CD, flash drive or other item that
is distributed?
* What if the document is on your own computer, but not
distributed to anyone? Might that be considered "pre-decisional" or
sort of like "raw footage"?

4.) Question #4: Having pushed through the issues of whether electronic
is covered, what type of content is covered, and how location of the
content might affect the determination of coverage, there is still
another outstanding matter: What actual design requirements are
necessary to ensure accessibility of electronic content?

You might imagine documents when answering this, but remember that
documents are not the only kind of electronic content. This is a
frequently asked question: "Can you tell me what to do to ensure that my
PDF document meets 508?" Are the current 508 standards woefully short in
electronic content provisions?

* Are there existing voluntary consensus standards that can be
referenced in the updated 508 standards? (Adobe > Isn't there work on
developing one for PDFs? - And if so, what is the estimated completion
timeline?)
* What do you think about 1194.22(a) being used to justify why
PDFs are covered. Do you think that is a stretch? Is that provision
really meant for things like photos and illustrations?
* Tables, maps and eletronic forms are specifically mentioned in
the current standards. What else might a robust set of standards for
electronic content address?
* A frequently asked question is: "What should I write in the alt
tag?" Would the Committee like to tackle the art of determining
sufficiency in text equivalents for non-text elements? Maybe this could
at least be an advisory note?
* E-learning generates serious complaints. Is the problem simply
that the 508 standards are fine but companies are not just implementing
them? Or might the problem also be that there is a need to add or change
some requirements in order to address learning management systems and
e-courses? It is this second question that we are concerned with. Given
the government's increased use of e-training, it is important to get
this right and contact all the necessary experts you can think of to
make sure you didn't miss anything.
* Logical reading order is an example of a specific issue that
some people think needs to be addressed in the refreshed standards. That
might be an example of how a usability issue gets reframed as an
accessibility issue? How can be this be address through an enforceable
requirement? Isn't the term "logical" arbitrary? Is there a voluntary
consensus standard on this that can be referenced? Of course, before
discussing this, you should first decide whether electronic content is
covered under 508.
* By the way, have you considered that this issue could end up
being applied to 255? Has the Committee seen a demonstration of how a
website could be used by all employees to control settings for their
VoIP telephone system? Do you want to handle this jointly with the
telecom subcommittee, instead of deferring it?

David Baquis
Accessibility Specialist
U.S. Access Board
1331 F Street, NW, #1000
Washington, DC 20004
800-USA-ABLE; (202) 272-0013 (voice)
www.access-board.gov; = EMAIL ADDRESS REMOVED = "Leading the way to
excellence in accessibility"

"Thank you for your questions concerning section 508 of the
Rehabilitation Act Amendments of 1998. Section 508 authorizes the
Access Board to provide technical assistance to individuals and Federal
departments and agencies concerning the requirements of this section.
This technical assistance is intended solely as informal guidance; it is
not a determination of the legal rights or responsibilities of entities
subject to section 508."


-----Original Message-----
From: Jim Tobias [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Thursday, October 26, 2006 8:15 AM
To: = EMAIL ADDRESS REMOVED =
Cc: Creagan Tim; Capozzi David; Baquis David ; Bailey Bruce
Subject: "Content" in our subcommittee

Hi,

The Group B wiki page does a great job of pulling out the provisions in
21
and 22 that address content (rather than navigation or operation). But
I'm
not sure if it hits the issue presented to us by the Access Board. If I
remember correctly, they had gotten a lot of questions about whether
documents attached to email, like a Word file with an image, was covered
by
508 and if so, did they require some other sort of technical solution.

1. Am I right in stating your concern, Access Board folks?
2. Is Group B on the right track for that concern?

******
Jim Tobias
Inclusive Technologies
= EMAIL ADDRESS REMOVED =
+1 732.441.0831 voice/tty
skype jimtobias
+1 908.907.2387 mobile

From: Salaets, Ken
Date: Mon, Oct 30 2006 3:40 PM
Subject: Re: "Content" in our subcommittee

Hi David. In an email message today, you stated: "So the Committee
needs to deliberate on the yes or no question of whether it was the
intention of the law to address accessibility of electronic content." I
would like to offer a complementary recommendation, if I may.

I believe that it would be very helpful to this subcommittee - and
TEITAC as a whole - if the Access Board staff would provide information
on this issue similar to that which is being developed in response to an
earlier Subpart A Subcommittee request. In other words, please collect
and make available the original analysis and information that led to the
first Advisory Committee's recommendation or recommendations on this
matter, as well as the analysis and information that staff provided to
the Access Board that resulted in the issuance of the current 5 0 8
standards. I believe that such information would serve as an invaluable
resource in helping us consider the task that you have suggested
relative to electronic content.

Thanks, David.

Ken Salaets
I T I

From: Jonathan Avila
Date: Tue, Oct 31 2006 6:30 AM
Subject: Re: "Content" in our subcommittee

" [David wrote] Question #1: Is electronic content covered under 508?"
And
"2.) Question #2: If electronic content is covered under 508, then what kind
of information and data is covered? "

My comments - I believe the current law is very clear that all of this is
covered, all means of E&IT regardless of how it is stored. The real
question is what can be enforced. Currently only E&IT that is procured is
enforced to these requirements. Thus, the obligation is already there to
ensure every type of E&IT meet the standards. Do we want to increase the
scope of enforcement?

Jonathan

From: Brett, Thomas F
Date: Tue, Oct 31 2006 6:35 AM
Subject: Re: "Content" in our subcommittee

Just focusing on email content I believe it is important that Section
508 clarify that this content and any attachments be available to people
with disabilities in a form that will allow them to read and complete
forms, if any.

As a economic benefit to enforcing compliant email content, Government
agencies send out email that have attachments related to HR and
Financial Guidance. These attachments are in PDF, Word or Excel format.
This guidance is posted to the receiving agency's web site. Before it
can be posted each of the agencies must convert the non compliant
guidance to a compliant format. If the sending agency has a list serv
that has 250 destinations that is 250 times that the document will be
made compliant so it can be posted. If the originating agency were
required to send a compliant attachment there would be significant
savings.

Tom Brett,
Section 508 Coordinator
US Office of Personnel Management
Rm 6H34A
2026061206 (v)
2026062582 (tty)
Disabled does not mean Unable
= EMAIL ADDRESS REMOVED =

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
Jonathan Avila
Sent: Tuesday, October 31, 2006 8:25 AM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] "Content" in our subcommittee

" [David wrote] Question #1: Is electronic content covered under 508?"
And
"2.) Question #2: If electronic content is covered under 508, then what
kind
of information and data is covered? "

My comments - I believe the current law is very clear that all of this
is
covered, all means of E&IT regardless of how it is stored. The real
question is what can be enforced. Currently only E&IT that is procured
is
enforced to these requirements. Thus, the obligation is already there
to
ensure every type of E&IT meet the standards. Do we want to increase
the
scope of enforcement?

Jonathan

From: Hoffman, Allen
Date: Tue, Oct 31 2006 6:45 AM
Subject: Re: "Content" in our subcommittee

Jonathan Avila wrote:
"My comments - I believe the current law is very clear that all of this
is covered, all means of E&IT regardless of how it is stored. The real
question is what can be enforced. Currently only E&IT that is procured
is enforced to these requirements. Thus, the obligation is already
there to ensure every type of E&IT meet the standards. Do we want to
increase the scope of enforcement?"

I feel enforceability is not within the scope of the TEITAC mission or
authority. Also, from the Federal perspective, the analogy we use is
the speed-limit. Speed limits are only enforceable when the enforcers
are on the scene in one way or another, it doesn't mean you are allowed
to speed when nobody is watching. Many Federal Departments and agencies
address other-than--procured EIT by internal policies and procedures,
but you are right that content would definitely most likely fall into
the developed category far more than acquired EIT. I wonder if the
content portion of software/web/content needs some more solid
connectivity with the subpart-a group, as these issues are cross
boundary all around. If subpart-a concludes content isn't in the scope,
then software/web/content produces usable standards for content, we
might be at odds.

The entire" is content included" debate has people with considerable
knowledge and experience in the field really split from my experience.
Personally I can't see how content is not included, but well informed
others concluded it was not the intent to include content, but rather
the delivery mechanisms. I just never thought that made a lot of sense
to require that you be given inaccessible information--what would be the
point of doing so.

From: Jonathan Avila
Date: Tue, Oct 31 2006 8:15 AM
Subject: Re: "Content" in our subcommittee

"other-than--procured EIT by internal policies and procedures, but you are
right that content would definitely most likely fall into the developed
category far more than acquired EIT. I wonder if the content portion of
software/web/content needs some more solid connectivity with "

[my comments] The law goes so far as to say any E&IT that is even "used" is
covered. Thus, technically an agency would need to review their use of
public domain software. Of course this is not enforceable though.

Jonathan

From: Fratkin, Mike
Date: Wed, Nov 01 2006 7:10 AM
Subject: Re: "Content" in our subcommittee

Allen Hoffman wrote:

"I feel enforceability is not within the scope of the TEITAC mission or
authority. Also, from the Federal perspective, the analogy we use is
the speed-limit. Speed limits are only enforceable when the enforcers
are on the scene in one way or another, it doesn't mean you are allowed
to speed when nobody is watching. Many Federal Departments and agencies
address other-than--procured EIT by internal policies and procedures,
but you are right that content would definitely most likely fall into
the developed category far more than acquired EIT. I wonder if the
content portion of software/web/content needs some more solid
connectivity with the subpart-a group, as these issues are cross
boundary all around. If subpart-a concludes content isn't in the scope,
then software/web/content produces usable standards for content, we
might be at odds.

The entire" is content included" debate has people with considerable
knowledge and experience in the field really split from my experience.
Personally I can't see how content is not included, but well informed
others concluded it was not the intent to include content, but rather
the delivery mechanisms. I just never thought that made a lot of sense
to require that you be given inaccessible information--what would be the
point of doing so."



I concur completely with Allen that it makes no sense to be given
inaccessible information whether it is from an e-mail or from a tool. It
may have been the intent originally of Section 508 to only address the
delivery mechanism, but the content should be considered at this time.

It seems to make little sense to spend resources to test an interface
for a viewer, the tool to produce electronic forms, the player or
learning management system for electronic learning, and terminal
emulators that display mainframe applications and then ignore the
content which is typically the most important element. The Federal
Government is currently struggling with electronic courseware that is
delivered by multiple sources, electronic forms produced by a variety of
tools and tools that produce PDF documents on the fly from mainframe
databases. All of this content from the various sources seems to be
analogous to what is developed by web tools and then delivered by
browsers. Content is becoming a very significant aspect of electronic
information and needs to be considered going forward.

Mike Fratkin
SSA

From: Jim Tobias
Date: Wed, Nov 01 2006 8:20 AM
Subject: Re: "Content" in our subcommittee

> The entire" is content included" debate has people with
> considerable knowledge and experience in the field really
> split from my experience.
> Personally I can't see how content is not included, but well
> informed others concluded it was not the intent to include
> content, but rather the delivery mechanisms. I just never
> thought that made a lot of sense to require that you be given
> inaccessible information--what would be the point of doing so."
>
> I concur completely with Allen that it makes no sense to be
> given inaccessible information whether it is from an e-mail
> or from a tool. It may have been the intent originally of
> Section 508 to only address the delivery mechanism, but the
> content should be considered at this time.
>
> It seems to make little sense to spend resources to test an
> interface for a viewer, the tool to produce electronic forms,
> the player or learning management system for electronic
> learning, and terminal emulators that display mainframe
> applications and then ignore the content which is typically
> the most important element.

I agree 100% with Mike and Allan. I myself have not heard a credible
argument in favor of excluding content from 508. Can someone please make
such an argument, or point us to one?

I think that this issue arises from a confusion about roles. In brief, I
think it may be industry saying "We can make tools that allow, and even
promote, the creation of accessible content, but maybe we cannot make tools
that disallow the creation of inaccessible content." I agree with this
statement -- you can't blame the car manufacturer for people driving too
fast. The "drivers" are the federal workforce, and they are responsible for
the actual accessibility of the content.

The "handoff" in this accessibility value chain could certainly be argued.
Do tools have to provide contextual help, as in "I see you're pasting an
image into this document. You may be required to add a text description.
Would you like to do that now?" Instead, should federal employees receive
tool-based training on creating accessible content? Regardless of what the
decisions are, there does need to be an assignment or understanding of
overall shared responsibility.

From: Brett, Thomas F
Date: Wed, Nov 01 2006 8:45 AM
Subject: Re: "Content" in our subcommittee

> I agree 100% with Mike and Allan. I myself have not heard a credible

>argument in favor of excluding content from 508. Can someone please
make

>such an argument, or point us to one?



A couple of thoughts regarding the laws dealing with Section 508...



* 1194.1 states in part "...access to and use of information and
data ..."

* it is generally understood that the definition of EIT in
Section 508 derives its definition from the Clinger - Cohen Act. The OMB
interpretation of Clinger-Cohen in Appendix IV to OMB Circular No A-130
would support that content should be included in the standards. The
following link is supplied in support of including content as part of
the Section 508 guidance:
http://www.whitehouse.gov/omb/circulars/a130/a130appendix_iv.html



which states:



The definition of "government information" includes information created,
collected, processed, disseminated, or disposed of both by and for the
Federal Government. This recognizes the increasingly distributed nature
of information in electronic environments.



Tom Brett,

Section 508 Coordinator

US Office of Personnel Management

Rm 6H34A

2026061206 (v)

2026062582 (tty)

Disabled does not mean Unable

= EMAIL ADDRESS REMOVED =



-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim
Tobias
Sent: Wednesday, November 01, 2006 10:17 AM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] "Content" in our subcommittee



> The entire" is content included" debate has people with

> considerable knowledge and experience in the field really

> split from my experience.

> Personally I can't see how content is not included, but well

> informed others concluded it was not the intent to include

> content, but rather the delivery mechanisms. I just never

> thought that made a lot of sense to require that you be given

> inaccessible information--what would be the point of doing so."

>

> I concur completely with Allen that it makes no sense to be

> given inaccessible information whether it is from an e-mail

> or from a tool. It may have been the intent originally of

> Section 508 to only address the delivery mechanism, but the

> content should be considered at this time.

>

> It seems to make little sense to spend resources to test an

> interface for a viewer, the tool to produce electronic forms,

> the player or learning management system for electronic

> learning, and terminal emulators that display mainframe

> applications and then ignore the content which is typically

> the most important element.



I agree 100% with Mike and Allan. I myself have not heard a credible

argument in favor of excluding content from 508. Can someone please
make

such an argument, or point us to one?



I think that this issue arises from a confusion about roles. In brief,
I

think it may be industry saying "We can make tools that allow, and even

promote, the creation of accessible content, but maybe we cannot make
tools

that disallow the creation of inaccessible content." I agree with this

statement -- you can't blame the car manufacturer for people driving too

fast. The "drivers" are the federal workforce, and they are responsible
for

the actual accessibility of the content.



The "handoff" in this accessibility value chain could certainly be
argued.

Do tools have to provide contextual help, as in "I see you're pasting an

image into this document. You may be required to add a text
description.

Would you like to do that now?" Instead, should federal employees
receive

tool-based training on creating accessible content? Regardless of what
the

decisions are, there does need to be an assignment or understanding of

overall shared responsibility.

From: Sean Hayes
Date: Wed, Nov 01 2006 9:20 AM
Subject: Re: "Content" in our subcommittee

> I myself have not heard a credible

>argument in favor of excluding content from 508. Can someone please
make

>such an argument, or point us to one?



Perhaps one differentiating factor is the extent to which the content is
being procured by a federal agency. For example if an agency comissions
an online help manual, it would make some sense if the manual were
treated as a product being procured and hence subject to constraints. On
the other hand, a document sent to a federal employee in the course of
an ordinary negotiation would remain copyright, and hence owned, by the
sender, and thus would not be 'procured' by the agency and so might be
exempt.



This has some practical merit - it would not be sensible for example to
fill in a VPAT for each email you need to send.



But even in the first case, content is not by itself accessible (or not)
- it has to be rendered by some software in some sensory modality; so
the question really applies to the combination of data and algorithm and
whether the algorithm is able to reconstruct the required information
from the received data.



I don't think a distinction as to whether the rendered information is
being created from data internal to the software, or received from an
external source is the problem, the important point is if the resulting
rendered form can be perceived by all users. I would argue that content
is not excluded from the current guidelines, but the guidelines sensibly
focus on outcomes.

* For example: 21(i) Color coding shall not be used as the only
means of conveying information, indicating an action, prompting a
response, or distinguishing a visual element.

Whether the colour is encoded in received data or not is not really
material, the requirement is that it not be the only means of conveying
information. The alternate means could be carried in the data, or it
could be carried in the algorithm (from an alternate built in stylesheet
for example). I think the regulations should continue to be outcome
based, and not process based.



I agree it does make some sense to require that creation tools
(particularly WYSIWYG ones) ask authors to consider alternate modalities
of presentation than the one being used to author the content as well as
other rendering tools.



---

Sean Hayes
Microsoft

From: Cyndi Rowland
Date: Wed, Nov 01 2006 10:10 AM
Subject: Re: "Content" in our subcommittee

>
>Perhaps one differentiating factor is the extent to which the
>content is being procured by a federal agency. For example if an
>agency comissions an online help manual, it would make some sense if
>the manual were treated as a product being procured and hence
>subject to constraints. On the other hand, a document sent to a
>federal employee in the course of an ordinary negotiation would
>remain copyright, and hence owned, by the sender, and thus would not
>be 'procured' by the agency and so might be exempt.
>
>
>
>This has some practical merit - it would not be sensible for example
>to fill in a VPAT for each email you need to send.

It seems to me that the very heart of all Web technologies is the
intent to deliver content. So I don't understand why we would want
to draw arbitrary lines around which content is developed and
delivered in a way consistent with the intent of the Rehab Act and
which content is not. In my opinion, if it is delivered as part of
electronic information technology (yes, including CD's & emails or
any other mechanism) it would fall under the applicable provisions of
Section 508 standards. Although a VPAT might be written for the email
program (to declare it's output as conformant to Section 508
standards), I don't see that anyone would think VPAT's would be
needed for every email.
>

From: Hoffman, Allen
Date: Wed, Nov 01 2006 10:20 AM
Subject: Re: "Content" in our subcommittee

I'm sure I haven't walked through this fully, but this may be a good
starter to get discussion going.

Here are the basic questions as I see this:

1. Is content addressed by Section 508?
2. Is content EIT?
3. How is content addressed currently?
4. Is content lagging behind due to missing EIT standards?
5. How should content be addressed better?
6. What would the impact of such change be?

1. Is content addressed by Section 508?
Content is information or data, and is thereby directly or indirectly
addressed by Section 508. Simple statement, it doesn't make practical
sense to ensure access to inaccessible information or data.

2. Is content EIT?
If it is included under electronic and information technology is a good
question, and the answer is probably no. Content is *not* technology,
but information associated with a storage, encoding, or presentation
mechanism, which may be technology. For example, you can read a
document on a piece of paper as the presentation mechanism, so it is
*not* technology, but you can also display it on the computer screen,
which is. A movie is a set of images which can be stored in analog
fashion on film, isn't technology, but the cameras, projectors, and
screens are.

3. How is content addressed currently?
Currently the standards include content requirements for information
encoded using HTML or directly linked to by HTML-based user-agents.
This sets a standard that content is included as part of the EIT
standards. HTML is only one encoding mechanism, and in fact has been
updated since the standards were written.

4. Is content lagging behind due to missing EIT standards?
Content is not addressed sufficiently for encoding mechanisms other than
HTML. No standards exist for content development/production systems
which often lack the basic capacity to include the required
accessibility attributes to achieve Section 508 compliance. video and
multimedia content problems can be overcome via technical refinements to
include audible navigation requirements. content from
telecommunications systems has a requirement already, but no supporting
standards really. For example, while interactive voice response systems
must be usable by people using a TTY, no standards for how that voice
information must be represented to the TTY is included.

5. How should content be addressed better?
To address this fundamental gap, or obstacle, it is important to develop
specific EIT content production systems functionality standards first.
Possible functionality might include the ability for content production
mechanisms to programmatically review user-developed content for missing
accessibility attributes, guide users to include accessibility
attributes during the development process by default, and allow
interactive remediation for missing accessibility attributes. I think
these requirements would fall into the web or software categories that
exist now, or would fall into a new category specifically related to
content that might include content production mechanisms, and content
requirements together. new general content requirements might be based
from the existing web standards, and may include, text alternatives for
non-text elements, visual reading order is available to assistive
technology, tabular header and cell associations, alternate or
additional representation of color, etc. I feel that form elements are
strictly web or software-based, and if provided via a plug-in (ahem
PDF), should be tested based upon software requirements.

6. What would the impact of such change be?
Electronic content is generally produced currently in the least time
possible, and most often by nontechnical personnel. Including technical
accessibility requirements in this process is a fundamental change for
the people who do the work. Without available technical aids to
expedite and guide content producers to develop content in the
technically correct way, with the minimum amount of information
sufficient to achieve the accessibility objectives, the economic impact
of content requirements I believe would be very great, and for many
would be considered an undue burden. A combination of content
development/production systems functionality requirements and general
content accessibility requirements in a matched set may drastically
lower the impact of such broadening of the current standards to the
point where it is feasible, and not an undue burden. This paired
approach, for example, might allow for one format to be preferred over
another since accessibility can be achieved using production systems
that support accessibility requirements. Over time by selecting
production systems which include more and more capacities to produce
accessible content with the minimum of effort, content will become more
accessible as well.

Finally:

I think the whole issue around if email is covered is not the most
critical question. It doesn't matter if email is covered or not if no
clear path to actually achieving the objective is available. My simple
answer regarding the email question, however, is that yes it is covered,
but primarily only for one-to-many emails, not for one-on-one emails.

Some other thoughts that come to mind when this topic comes up include:

Does anyone have a good set of requirements that could be used to
address such content as flow-charts, org-charts, etc. I have seen good
information on "how to" make them accessible, but never seen anything
yet that could be a set of requirements or standards. My view on such
content is that it is a set of related objects, each with attributes,
and that the visual representation rarely includes those attributes in a
nonvisual format because the tools don't offer that view, or input
method. If, for example, a flow-charting package included the ability
to list the objects and their relationships from a flow chart, then
someone with a visual disability could walk the objects and follow the
flow.

Allen Hoffman
Department of homeland Security
Office on Accessible Systems & Technology






Allen Hoffman
DHS : CRCL & OCIO;
DHS Office On Accessible Systems and Technology
v: 202-447-0303; c: 202-213-1835; tty: 202-401-0725
email: = EMAIL ADDRESS REMOVED = or = EMAIL ADDRESS REMOVED =

This communication, along with any attachments, is covered by federal
and state law governing electronic communications and may contain
sensitive and legally privileged information. If the reader of this
message is not the intended recipient, you are hereby notified that any
dissemination, distribution, use or copying of this message is strictly
prohibited. If you have received this in error, please reply
immediately to the sender and delete this message.
Thank you.

From: Sean Hayes
Date: Wed, Nov 01 2006 11:10 AM
Subject: Re: "Content" in our subcommittee

<quote cyndi rowland>In my opinion, if it is delivered as part of
electronic information technology (yes, including CD's & emails or any
other mechanism) it would fall under the applicable provisions of
Section 508 standards. Although a VPAT might be written for the email
program (to declare it's output as conformant to Section 508 standards),
I don't see that anyone would think VPAT's would be needed for every
email.

</quote>



I don't disagree with you that content is part of EIT, or that it falls
under the provisions, Indeed I believe it is already covered in the
existing provisions, and it would be a significant change to remove it.



The issues seem to me to firstly be in identifying who is the author and
thus who carries the responsiblity for ensuring the content meets the
provision, and secondly in crafting the provisions so that the desired
outcome is achieved, i.e. that the recipient can actually use the
content.



In the email case, the VPAT for your email client would not cover the
emails you as Cyndi Rowland write, you (or your employer) would be
responsible for those if they were not accesible and were being procured
or used by a Federal agency.



Likewise, the email client being used by the Federal agency is
responsible for rendering to the best of its ability the information it
receives in accordance with the 508 provisions (possibly in conjunction
with some AT). If you as an author fail to provide the necessary
information in your email, it is not the fault of the email client if it
cannot render it, but it would be the fault of the client if you did
provide the information and the client did not render it.



Similar arguments apply for web content, it is up to the web author to
ensure the provision of information; the web content format designer to
ensure that information can be transmitted, and the web browser to
render that information appropriately. Only if all parts of the chain
are properly linked can accessibility be guaranteed

Sean Hayes
Microsoft

From: Fratkin, Mike
Date: Wed, Nov 01 2006 11:35 AM
Subject: Re: "Content" in our subcommittee

Content may be covered under Section 508, but it may not be completely
understood by industry. When we receive a VPAT for a tool that produces
content (and not necessarily Web based), the standards are referenced
for the tool and not the ability to produce compliant content. How does
the purchaser know when looking at several e-forms tools, for example,
which ones has the capability to produce compliant forms? For electronic
learning, there are currently 50 contracts for a variety of components
with several of them for courseware. These companies provide software
to produce courseware and the vehicles to play them. Courseware can
consist of lessons, tests, simulations and course completion progress
statistics and charts. There does not seem to be sufficient guidelines
provided from Section 508 for these types of content. Vendors seem only
to address the tools, players and other delivery mechanisms.

The same can be said, for instance, for a spreadsheet program like
Excel. We constantly here the statement that Excel is Section 508
compliant but do not understand completely that when they produce an
application within that spreadsheet program with fields and checkboxes
and other controls that it does not automatically become compliant. This
has been a constant theme for many web based development tools for
report and chart generation, collaboration, web analysis and document
viewers.

Mike Fratkin
SSA

Sean Hayes wrote:

I don't disagree with you that content is part of EIT, or that it falls
under the provisions, Indeed I believe it is already covered in the
existing provisions, and it would be a significant change to remove it.



The issues seem to me to firstly be in identifying who is the author and
thus who carries the responsiblity for ensuring the content meets the
provision, and secondly in crafting the provisions so that the desired
outcome is achieved, i.e. that the recipient can actually use the
content.



In the email case, the VPAT for your email client would not cover the
emails you as Cyndi Rowland write, you (or your employer) would be
responsible for those if they were not accesible and were being procured
or used by a Federal agency.



Likewise, the email client being used by the Federal agency is
responsible for rendering to the best of its ability the information it
receives in accordance with the 508 provisions (possibly in conjunction
with some AT). If you as an author fail to provide the necessary
information in your email, it is not the fault of the email client if it
cannot render it, but it would be the fault of the client if you did
provide the information and the client did not render it.



Similar arguments apply for web content, it is up to the web author to
ensure the provision of information; the web content format designer to
ensure that information can be transmitted, and the web browser to
render that information appropriately. Only if all parts of the chain
are properly linked can accessibility be guaranteed


_____

From: Jim Tobias
Date: Wed, Nov 01 2006 11:45 AM
Subject: Re: "Content" in our subcommittee

Let me propose that we consider the following requirements for industry of
content-producing software tools:

1. The tool itself should be accessible to operate. (This would apply to
all software, not just content-producing software).
2. The content produced by the tool should be able to support all the
relevant features for accessible content.

And the following requirement should apply to the federal entity producing
the content:

3. The content should contain all the relevant features for accessible
content.


***********
Jim Tobias
Inclusive Technologies
= EMAIL ADDRESS REMOVED =
+1.732.441.0831 v/tty
skype jimtobias
www.inclusive.com

From: Laura Ruby
Date: Wed, Nov 01 2006 11:55 AM
Subject: Re: "Content" in our subcommittee

What is a "content-producing software tool"?

Laura Ruby
Director of Policy and Standards
Microsoft Accessible Technology Group
425-705-7098
= EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >

From: Sean Hayes
Date: Wed, Nov 01 2006 12:00 PM
Subject: Re: "Content" in our subcommittee

>>. The content should contain all the relevant features for accessible
content.



> I am confused...why would it be The content will be accessible



Agreed. I would suggest rather something along the lines of:



"Content should retain sufficient information to be reconstituted into
an accessible form by a subsequent tool"

Sean Hayes
Microsoft

From: Hoffman, Allen
Date: Wed, Nov 01 2006 12:05 PM
Subject: Re: "Content" in our subcommittee

Jim Tobias wrote:
"1. The tool itself should be accessible to operate. (This would apply
to all software, not just content-producing software).
2. The content produced by the tool should be able to support all the
relevant features for accessible content.
And the following requirement should apply to the federal entity
producing the content:
3. The content should contain all the relevant features for accessible
content."

Allen hoffman wrote:
"5. How should content be addressed better?
To address this fundamental gap, or obstacle, it is important to develop
specific EIT content production systems functionality standards first.
Possible
functionality might include the ability for content production
mechanisms to programmatically review user-developed content for missing
accessibility attributes,
guide users to include accessibility attributes during the development
process by default, and allow interactive remediation for missing
accessibility
attributes. I think these requirements would fall into the web or
software categories that exist now, or would fall into a new category
specifically related
to content that might include content production mechanisms, and content
requirements together. new general content requirements might be based
from the
existing web standards, and may include, text alternatives for non-text
elements, visual reading order is available to assistive technology,
tabular header
and cell associations, alternate or additional representation of color,
etc. I feel that form elements are strictly web or software-based, and
if provided
via a plug-in (ahem PDF), should be tested based upon software
requirements."

I am not certain Jim's summary includes some of mine. I just don't
think we can move into the vast content area without sufficient
technical support and not impose a huge cost. Without spell check,
spelling would go down for government documents. Without "access
check/repair" content accessibility will not improve quickly in my
opinion. At least most folks understand that they should spell words
correctly, but this is not the case, as far as I can tell, for the
majority of documents writers out there.

Allen Hoffman
Department of Homeland Security
Office on Accessible systems & technology

From: Brett, Thomas F
Date: Wed, Nov 01 2006 12:10 PM
Subject: Re: "Content" in our subcommittee

>. The content should contain all the relevant features for accessible
content.



I am confused...why would it be The content will be accessible



Tom Brett,

Section 508 Coordinator

US Office of Personnel Management

Rm 6H34A

2026061206 (v)

2026062582 (tty)

Disabled does not mean Unable

= EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Laura
Ruby
Sent: Wednesday, November 01, 2006 1:50 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] "Content" in our subcommittee



What is a "content-producing software tool"?



Laura Ruby

Director of Policy and Standards

Microsoft Accessible Technology Group

425-705-7098

= EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >

From: Andrew Kirkpatrick
Date: Wed, Nov 01 2006 12:15 PM
Subject: Re: "Content" in our subcommittee

> What is a "content-producing software tool"?

I'm a little confused about the definition of "content" here. When we
(Adobe) write the VPAT for Dreamweaver or other tools that create web
pages or applications we evaluate the tool's output as well as its use,
but I'm not clear where the line is drawn between content and
application or between content and web page.

Can someone clarify what the definition of content is?

AWK

From: Sailesh Panchang
Date: Mon, Nov 06 2006 3:56 PM
Subject: Re: "Content" in our subcommittee

>Let me propose that we consider the following requirements for industry of
content-producing software tools:

> 1. The tool itself should be accessible to operate. (This would apply to
all software, not just content-producing software).

This is really needed. it will make companies regard authoring tools
accessibility guidelines (ATAG) more seriously.



>2. The content produced by the tool should be able to support all the
relevant features for accessible content.



>And the following requirement should apply to the federal entity producing
the content:

> 3. The content should contain all the relevant features for accessible
content.

How can this be part of the S508 standards. it is upto the user how the tool
is used and cannot be part of procurement precondition.



Sailesh Panchang
Senior Accessibility Engineer
Deque Systems Inc. (www.deque.com)
11130 Sunrise Valley Drive, Suite #140,
Reston VA 20191
Phone: 703-225-0380 (ext 105)
E-mail: = EMAIL ADDRESS REMOVED =



*

From: Jim Tobias
Date: Mon, Nov 06 2006 3:58 PM
Subject: Re: "Content" in our subcommittee

_____

From: Sailesh Panchang [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Wednesday, November 01, 2006 5:42 PM
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] "Content" in our subcommittee



<snip>



>And the following requirement should apply to the federal entity producing
the content:

> 3. The content should contain all the relevant features for accessible
content.

How can this be part of the S508 standards. it is upto the user how the tool
is used and cannot be part of procurement precondition.



The law refers to "developing, procuring, maintaining, or using electronic
and information technology". So the first, fourth and possibly the third
term refers not to the vendor but to the agency itself.

From: Barrett, Don
Date: Mon, Nov 06 2006 3:59 PM
Subject: Re: "Content" in our subcommittee

Since only procurement violations are subject to enforcement, do people
think that content standards will have any lasting impact?

From: Jim Thatcher
Date: Mon, Nov 06 2006 4:07 PM
Subject: Re: "Content" in our subcommittee

This content thread has troubled me from the beginning and the recent
message (with subject "RE: [teitac-websoftware] teitac-websoftware Digest,
Vol 2, Issue 4" (thanks a lot) brought my concerns to a head.



Michael raised the issue of Authoring Tools.



<blockquote>

This group (or some other standards group), needs to start putting together

guidelines for such tools, just as W3C has done. ...



This would mean any application (Word Processor, Spreadsheet, Flow-chart
app., etc.) used to create any content consumed by a human being. Of
course, the Authoring Tools themselves would need to be accessible as well
as their output

</blockquote>



I think that we cannot specify accessibility of content so generally defined
and the W3C referred to in Michaels post testifies to that.



The Web Accessibility Initiative has Authoring Tool Accessibility Guidelines
(ATAG, http://www.w3.org/TR/WAI-AUTOOLS/). Tools that produce web content
should be accessible and produce accessible content. Look at that document.
It punts on accessibility of the tool itself: "The authoring tool is a
software program with standard user interface elements and as such must be
designed according to relevant user interface accessibility guidelines." And
it relies on WCAG 1.0 for its definition of producing accessible content.



So the only example of authoring tool accessibility punts (looks elsewhere)
on both the issue of the output accessibility and tool accessibility! For
good reason!



I think the content idea (the content thread) is a red herring that has the
effect of diverting us from our important work. Those raising the issue
certainly did not have that intent; I have no doubt. Let me try to say why
it is a red herring.



The way we looked at software accessibility in EITAAC (I was chair of the
software committee) was that the applications consisted of a system of
windows (standard user interface elements in ATAG terminology) including
title bars, scroll bars, menus, toolbars, status areas, and the one big
window in the middle, called in those days, the client area - or content
area. All the subsidiary windows (objects, interface elements) needed to
provide name, state and role information and be accessible from the
keyboard, but for client area we were quiet because there was nothing we
could say except that text and its properties must be available to AT. So
basically, of "content" we only said provide text and text properties. (You
can generalize to non-text content).



Well not completely. When the software was a web browser, its client area
contained web pages - and the 508 provisions required that that "content" be
accessible in a different sense, a sense divorced from the software (the
browser). That said nothing about the browser. If the browser (a software
application) opens a web page which is totally inaccessible the software
program (browser) doesn't fail accessibility standards.



I think the 508 standards should require software accessibility and web
accessibility (including multimedia) but there is nothing we can say about
accessibility of the content that appears in an arbitrary "content" creating
application.



You cannot put accessibility requirements on that client area. As you work
on an image in Photoshop there is nothing about that content that is
accessible. As I create a table in Lotus 123 (yes I do!) there is nothing
accessible about the tables I am creating. What must be accessible is the
software. When I move around cells, focus is available to screen readers and
they can announce the contents of the cells, and the textual characteristics
of the contents. All the surrounding menus and dialogs must be accessible.
But about the actual tables, the actual content - we are silent. We have no
way to judge or measure that. If I work in a text editor, say WordPad or
SlickEdit (which I use) and I make some text bold - what should AT know?
They need to know the text and its properties, like being bold.



The only content we know how to address for accessibility is Web content.



Jim



Accessibility Consulting: http://jimthatcher.com/

512-306-0931

From: Hoffman, Allen
Date: Mon, Nov 06 2006 4:08 PM
Subject: Re: "Content" in our subcommittee

Jim Thatcher wrote:
"This content thread has troubled me from the beginning and the recent
message (with subject "RE: [teitac-websoftware] teitac-websoftware
Digest, Vol 2,
Issue 4" (thanks a lot) brought my concerns to a head."

it is a difficult issue I agree.

Jim Thatcher wrote:
"You cannot put accessibility requirements on that client area. As you
work on an image in Photoshop there is nothing about that content that
is accessible.
As I create a table in Lotus 123 (yes I do!) there is nothing accessible
about the tables I am creating. What must be accessible is the software.
When
I move around cells, focus is available to screen readers and they can
announce the contents of the cells, and the textual characteristics of
the contents.
All the surrounding menus and dialogs must be accessible. But about the
actual tables, the actual content - we are silent. We have no way to
judge or measure
that. If I work in a text editor, say WordPad or SlickEdit (which I use)
and I make some text bold - what should AT know? They need to know the
text and
its properties, like being bold.

The only content we know how to address for accessibility is Web
content."

I believe that other encoding/markup mechanisms include accessibility
attributes.

Your points are well taken, and bring me to the concept that the
encoding formats used must include specific accessibility attributes to
support specific accessibility functionalities. so how about something
such as:

Encoding formats used shall include or incorporate/support attributes
to: (insert list) such as, associate images with alternate text,
identify reading order, associate table headers and cells, provide
focus, identity, operation and state for input elements, (etc.). this
might even be something in the 1194.41 section.

Then, we might also insert in that area, or in software & web, something
like an ATAG requirement.

Content is really just content; it is the encoding mechanisms and
encoding tools that often are the factors to drive accessibility. Web
is often more accessible than other formats because, the format has
accessibility attributes available, requirements for those attributes to
be used, and some tools to help people encode the information with those
attributes.

I do agree these may be two tracks here--specific web/software
requirements, and content/format and tool requirements. Web
requirements are really format requirements, since no user-agent
requirements or authoring tool requirements are in place yet.
eventually it comes down to end-to-end coverage, gaps have and will
cause inaccessibility I believe.

allen Hoffman
Department of Homeland Security
Office on Accessible Systems & Technology