E-mail List Archives
Thread: Do doctype declarations change browser interpretations?
Number of posts in this thread: 6 (In chronological order)
From: Kilcommons,Cath
Date: Fri, Mar 15 2002 12:08PM
Subject: Do doctype declarations change browser interpretations?
No previous message | Next message →
An instructional designer was asking me about doctype declarations (dtd), and asked if they actually would effect the way a browser interprets the document. I thought this group might have some insight into that question.
Does anyone have info on this topic?
Thanks,
Cath
Cath Stager- Kilcommons
Assistive Technology Support and
Web Accessibility Coordinator
Assistive Technology Resource Center
<http://www.colostate.edu/Depts/ATRC>
Colorado State University
970-491-6258
= EMAIL ADDRESS REMOVED =
----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/
From: Sam Buchanan
Date: Fri, Mar 15 2002 12:41PM
Subject: Re: Do doctype declarations change browser interpretations?
← Previous message | Next message →
Kilcommons,Cath wrote:
> An instructional designer was asking me about doctype declarations
> (dtd), and asked if they actually would effect the way a browser
> interprets the document. I thought this group might have some
> insight into that question.
>
> Does anyone have info on this topic?
Yes. Start here, where you'll find pretty much everything you need to
know:
http://gutfeldt.ch/matthias/articles/doctypeswitch.html
----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/
From: Sharon Daniels
Date: Fri, Mar 15 2002 2:25PM
Subject: Section 508 1194.22(p)
← Previous message | Next message →
Our agency is trying to deal with this guideline. 1194.22(p) We have made
our vendor create an application for us and they are developing it all
server side in Java. This guideline says that when you have a timed
response you have to alert the user and give them sufficient time to
indicate that more time is required. First of all, is a timed response the
same as the "time-out" for inactivity? And if so, if you can't use
Javascript (or if it also has to work without Javascript, too) - how would
you alert the user using a server side language?
If we set a 15 minute time out for inactivity on the server side, does it
only keep track of activity such as a submit button, or next page. If it is
server side it can't track mouse activity or keystrokes - is that correct?
So the user would have to fill out a form within the 15 minutes in order to
not time out. How would you let them know their time is almost up and let
them request more time?
The vendor is talking about writing a java applet that the user would have
to download in order to track the time. Is that the best way?
Or maybe I am interpreting this all wrong and the "timed response" is not
the same as a time-out for inactivity?
Thank you for any information you can send my way.
Sharon
----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/
From: Paul Bohman
Date: Fri, Mar 15 2002 5:14PM
Subject: RE: Section 508 1194.22(p)
← Previous message | Next message →
Sharon, you have asked some good questions.
>> First of all, is a timed response the same as the "time-out" for
inactivity?
A strict interpretation of the law would say that yes, this is a timed
response. Some people (including myself) will argue that tome-outs must
be allowed under some circumstances (e.g. where security is very
important). Still, it is possible that you will exclude some people with
certain disabilities if you set a time-out, no matter how long the
interval is. It then becomes a question of where you draw the line.
>> And if so, if you can't use Javascript (or if it also has to work
without Javascript, too) - how would you alert the user using a server
side language?
You really can't. At least I can't think of a way. (I assume that you're
talking about server side languages such as JSP, PHP, Cold Fusion, Perl,
Python, ASP and the like.)
>> If we set a 15 minute time out for inactivity on the server side,
does it only keep track of activity such as a submit button, or next
page.
You are correct: If you set the time limit server-side, then you can
only keep track of events that are sent to the server. If someone
submits a page 16 minutes after the timer begins, then the page is late
and you can send back an error message.
>> If it is server side it can't track mouse activity or keystrokes - is
that correct?
To the best of my knowledge, that is correct.
>> So the user would have to fill out a form within the 15 minutes in
order to not time out.
Correct.
>> How would you let them know their time is almost up and let them
request more time?
You could post a text message telling them that their time will expire
in 15 minutes, but if you don't use client-side scripting of some sort,
you can't notify them until they submit the page.
>> The vendor is talking about writing a java applet that the user would
have to download in order to track the time. Is that the best way?
That will probably perform the necessary function, but it may not do it
in an accessible format. Your dilemma is a real-life example of someone
with good intentions (you) trying to design an accessible Web feature
within the constraints of other design considerations. Here are a few
thoughts:
Overall, Java is less accessible than JavaScript. If a time-out really
is necessary, then I would be inclined to set a timer both server-side
and client-side JavaScript.
* The server side script will generate an error message if the page is
submitted after the time out deadline. This will accomplish the goals of
your time-out functionality. You could also have a message at the top of
the page which says "You must submit this page in 15 minutes. If you
need more time, select the 'more time needed' button below." You could
then offer them more time (30 minutes, for example). It may or may not
be possible to offer them that much time. I don't know your
circumstances.
* You could also use a client-side JavaScript which will alert users
when they have 5 minutes left, and then the script could redirect the
page at the end of the time-out period. Most users of JAWS, Window Eyes,
and Home Page Reader will be able to access the JavaScript popup
messages. Some people will not, either because they are using a
different technology, or because they have JavaScript turned off. You
can't avoid this. The JavaScript will simply be inaccessible to a
portion of the population.
* Using Java will not solve any part of the accessibility problem. It
may make it possible to do time-outs, but people with disabilities will
not benefit from Java, especially in comparison to JavaScript, which is
somewhat more accessible when used wisely.
>> Or maybe I am interpreting this all wrong and the "timed response" is
not the same as a time-out for inactivity?
I believe that your interpretation is correct. You are also correct to
be concerned, but, as I said before, I believe that there are
circumstances in which the rules may need to bend a bit. You can't have
unlimited time to fill out a form and tight security at the same time.
You have to compromise one or the other.
The real question that you need to ask is "Is a time-out necessary?" If
it is, then you can follow my suggestions above, or come up with some
other creative workarounds. If it isn't necessary, then your problem is
solved: don't include a time-out.
Paul Bohman
Technology Coordinator
WebAIM (Web Accessibility in Mind)
www.webaim.org
Center for Persons with Disabilities
www.cpd.usu.edu
Utah State University
www.usu.edu
----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/
From: Sharon Daniels
Date: Mon, Mar 18 2002 6:17AM
Subject: Re: Section 508 1194.22(p)
← Previous message | Next message →
Paul -
Thanks so much for all this information. I will run all this by the
developers. A time out is necessary for us because people will be using
this application in public places and they will have to enter confidential
information. We need it to time out in case the user gets up in the middle
and walks away without getting out of the application. It's not totally
fool-proof but a small measure to try to keep the information as
confidential as possible.
----- Original Message -----
From: "Paul Bohman" < = EMAIL ADDRESS REMOVED = >
To: < = EMAIL ADDRESS REMOVED = >
Sent: Friday, March 15, 2002 7:14 PM
Subject: RE: Section 508 1194.22(p)
> Sharon, you have asked some good questions.
>
> >> First of all, is a timed response the same as the "time-out" for
> inactivity?
>
> A strict interpretation of the law would say that yes, this is a timed
> response. Some people (including myself) will argue that tome-outs must
> be allowed under some circumstances (e.g. where security is very
> important). Still, it is possible that you will exclude some people with
> certain disabilities if you set a time-out, no matter how long the
> interval is. It then becomes a question of where you draw the line.
>
> >> And if so, if you can't use Javascript (or if it also has to work
> without Javascript, too) - how would you alert the user using a server
> side language?
>
> You really can't. At least I can't think of a way. (I assume that you're
> talking about server side languages such as JSP, PHP, Cold Fusion, Perl,
> Python, ASP and the like.)
>
> >> If we set a 15 minute time out for inactivity on the server side,
> does it only keep track of activity such as a submit button, or next
> page.
>
> You are correct: If you set the time limit server-side, then you can
> only keep track of events that are sent to the server. If someone
> submits a page 16 minutes after the timer begins, then the page is late
> and you can send back an error message.
>
> >> If it is server side it can't track mouse activity or keystrokes - is
> that correct?
>
> To the best of my knowledge, that is correct.
>
> >> So the user would have to fill out a form within the 15 minutes in
> order to not time out.
>
> Correct.
>
> >> How would you let them know their time is almost up and let them
> request more time?
>
> You could post a text message telling them that their time will expire
> in 15 minutes, but if you don't use client-side scripting of some sort,
> you can't notify them until they submit the page.
>
> >> The vendor is talking about writing a java applet that the user would
> have to download in order to track the time. Is that the best way?
>
> That will probably perform the necessary function, but it may not do it
> in an accessible format. Your dilemma is a real-life example of someone
> with good intentions (you) trying to design an accessible Web feature
> within the constraints of other design considerations. Here are a few
> thoughts:
>
> Overall, Java is less accessible than JavaScript. If a time-out really
> is necessary, then I would be inclined to set a timer both server-side
> and client-side JavaScript.
> * The server side script will generate an error message if the page is
> submitted after the time out deadline. This will accomplish the goals of
> your time-out functionality. You could also have a message at the top of
> the page which says "You must submit this page in 15 minutes. If you
> need more time, select the 'more time needed' button below." You could
> then offer them more time (30 minutes, for example). It may or may not
> be possible to offer them that much time. I don't know your
> circumstances.
> * You could also use a client-side JavaScript which will alert users
> when they have 5 minutes left, and then the script could redirect the
> page at the end of the time-out period. Most users of JAWS, Window Eyes,
> and Home Page Reader will be able to access the JavaScript popup
> messages. Some people will not, either because they are using a
> different technology, or because they have JavaScript turned off. You
> can't avoid this. The JavaScript will simply be inaccessible to a
> portion of the population.
> * Using Java will not solve any part of the accessibility problem. It
> may make it possible to do time-outs, but people with disabilities will
> not benefit from Java, especially in comparison to JavaScript, which is
> somewhat more accessible when used wisely.
>
>
> >> Or maybe I am interpreting this all wrong and the "timed response" is
> not the same as a time-out for inactivity?
>
> I believe that your interpretation is correct. You are also correct to
> be concerned, but, as I said before, I believe that there are
> circumstances in which the rules may need to bend a bit. You can't have
> unlimited time to fill out a form and tight security at the same time.
> You have to compromise one or the other.
>
> The real question that you need to ask is "Is a time-out necessary?" If
> it is, then you can follow my suggestions above, or come up with some
> other creative workarounds. If it isn't necessary, then your problem is
> solved: don't include a time-out.
>
> Paul Bohman
> Technology Coordinator
> WebAIM (Web Accessibility in Mind)
> www.webaim.org
> Center for Persons with Disabilities
> www.cpd.usu.edu
> Utah State University
> www.usu.edu
>
>
>
>
>
> ----
> To subscribe, unsubscribe, or view list archives,
> visit http://www.webaim.org/discussion/
>
----
To subscribe, unsubscribe, or view list archives,
visit http://www.webaim.org/discussion/
From: Jim Thatcher
Date: Mon, Mar 18 2002 9:07AM
Subject: RE: Section 508 1194.22(p)
← Previous message | No next message
I believe that a timeout for inactivity is not an instance of "timed
responses" that are covered by 1194.22(p), especially when the inactivity is
five to ten times the normal inactivity. There many situations where sites
need to time out of a situation where the customer is "logged in" and doing
nothing. I wish the wording of ll94.22(p) were clearer but I think the alert
and provision for more time just doesn't work in typical site timeout
situations. The problem usually is that the person is no longer viewing
the page. The library example is perfect in this regard.
Jim
Accessibility Consulting
There's a new book on Web Accessibility. For information:
http://jimthatcher.com.