E-mail List Archives
Thread: Re: Focus for error messages
Number of posts in this thread: 19 (In chronological order)
From: Joshue O Connor
Date: Thu, Apr 19 2007 3:00AM
Subject: Re: Focus for error messages
No previous message | Next message →
Spruill Kevin wrote:
> if the error message is passed over by the auto focus, it really isn't
> being presented to the screenreader users.
Its really important that error messages are visible to screen reader
users (indeed all users), as and when they occur. How this is done would
be useful point for discussion on the list. I have seen many systems
where the error message is just not given focus and the user is often
unaware that anything is wrong until of course when they can no-longer
continue with what they are trying to do.
It think this aspect is often a serious flaw in otherwise good web
interfaces/applications.
Josh
********************************************************************
NOTICE: The information contained in this email and any attachments
is confidential and may be privileged. If you are not the intended
recipient you should not use, disclose, distribute or copy any of
the content of it or of any attachment; you are requested to notify
the sender immediately of your receipt of the email and then to
delete it and any attachments from your system.
NCBI endeavours to ensure that emails and any attachments generated
by its staff are free from viruses or other contaminants. However,
it cannot accept any responsibility for any such which are
transmitted. We therefore recommend you scan all attachments.
Please note that the statements and views expressed in this email
and any attachments are those of the author and do not necessarily
represent the views of NCBI
********************************************************************
From: ben morrison
Date: Thu, Apr 19 2007 3:30AM
Subject: Re: Focus for error messages
← Previous message | Next message →
On 4/19/07, Joshue O Connor < = EMAIL ADDRESS REMOVED = > wrote:
> Spruill Kevin wrote:
> > if the error message is passed over by the auto focus, it really isn't
> > being presented to the screenreader users.
>
> Its really important that error messages are visible to screen reader
> users (indeed all users), as and when they occur. How this is done would
> be useful point for discussion on the list. I have seen many systems
> where the error message is just not given focus and the user is often
> unaware that anything is wrong until of course when they can no-longer
> continue with what they are trying to do.
I have adopted an approach to using an ordered list showing all the
errors and sending the page to the error message, also changing the
page title to indicate an error has occurred.
You can see it in practice on this site:
http://www.ncpta.org.uk/form/100013/contact_us/
Gez Lemon also came up with a similar approach and has a good write up:
http://juicystudio.com/article/dom-screen-readers.php
ben
--
Ben Morrison
From: Karl Groves
Date: Thu, Apr 19 2007 7:20AM
Subject: Re: Focus for error messages
← Previous message | Next message →
>
From: tedd
Date: Thu, Apr 19 2007 7:30AM
Subject: Re: Focus for error messages
← Previous message | Next message →
At 9:10 AM -0400 4/19/07, Karl Groves wrote:
>
>
>Does anyone have any good examples of methods to supply error messages as
>they occur that are accessible?
>
>Karl
Karl:
Pardon me, I'm coming into this thread a little late, so I may be off
track, but if you use a new window to show error messages, then that
will be provided to screen readers.
Also, if you initiate a screen refresh of the current window, then
whatever errors that are new on that page (via ajax) will be made
accessible to screen readers as well.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
From: Rich Pedley
Date: Thu, Apr 19 2007 7:50AM
Subject: Re: Focus for error messages
← Previous message | Next message →
On 19/04/2007 14:24, tedd wrote:
> At 9:10 AM -0400 4/19/07, Karl Groves wrote:
>>
>> Does anyone have any good examples of methods to supply error
>> messages as they occur that are accessible?
>>
>> Karl
>
> Karl:
>
> Pardon me, I'm coming into this thread a little late, so I may be
> off track, but if you use a new window to show error messages, then
> that will be provided to screen readers.
>
> Also, if you initiate a screen refresh of the current window, then
> whatever errors that are new on that page (via ajax) will be made
> accessible to screen readers as well.
Surely when JAWS is in 'forms mode' unless the text of these errors is
put into the 'form' then they won't be heard? I have always assumed
that JAWS in 'forms' mode doesn't read out anything except the
standard form legends/labels/inputs, basically ignoring all other
text. Is that not so then?
Rich
From: Joshue O Connor
Date: Thu, Apr 19 2007 8:00AM
Subject: Re: Focus for error messages
← Previous message | Next message →
JAWS in forms mode is actually JAWS interacting directly with the web
interface/application itself. Otherwise the screen reader is interacting
with a virtual version of the page via the OSM (Off Screen Model). Many
screen readers use these methods and some interact directly through the
DOM such as Supernova/HAL.
tedd said:
> you use a new window to show error messages, then that will be provided to screen readers.
Thats one way but this may not always be ideal. Also, if the DOM is
being manipulated then these error messages may not be displayed at all
as the page is not refreshed when dynamically manipulating the DOM. You
may be able to trigger page refresh etc but I suppose this goes against
the grain of dynamically generating content on the fly a la AJAX.
> if you initiate a screen refresh of the current window, then whatever errors that are new on that page (via ajax) will be made accessible to screen readers as well.
Could you please expand a little on how you suggest that will work?
Ben pointed to some good resources earlier including his example and
Gez's article, which are really useful.
The real trick to give the error message focus within your interface and
in order to do that you need to provide an element that can receive
focus such as an anchor/link.
Cheers
Josh
********************************************************************
NOTICE: The information contained in this email and any attachments
is confidential and may be privileged. If you are not the intended
recipient you should not use, disclose, distribute or copy any of
the content of it or of any attachment; you are requested to notify
the sender immediately of your receipt of the email and then to
delete it and any attachments from your system.
NCBI endeavours to ensure that emails and any attachments generated
by its staff are free from viruses or other contaminants. However,
it cannot accept any responsibility for any such which are
transmitted. We therefore recommend you scan all attachments.
Please note that the statements and views expressed in this email
and any attachments are those of the author and do not necessarily
represent the views of NCBI
********************************************************************
From: Tim Harshbarger
Date: Thu, Apr 19 2007 8:10AM
Subject: Re: Focus for error messages
← Previous message | Next message →
Rich,
If displaying the errors causes the page to refresh, JAWS should revert
to virtual cursor mode unless the user has specifically altered the
settings that cause JAWS to turn off forms mode on a page refresh.
I am uncertain what the other screen readers do.
Tim
From: Jared Smith
Date: Thu, Apr 19 2007 8:40AM
Subject: Re: Focus for error messages
← Previous message | Next message →
On 4/19/07, Karl Groves wrote:
> Does anyone have any good examples of methods to supply error messages as
> they occur that are accessible?
We implemented a method that seems to work pretty well. It doesn't do
it 'live', but after the form is submitted. You can try it out at
http://webaim.org/contact/ (just leave a field blank, no worries if
you accidentally send a message). It uses javascript to visually
highlight the error messages as well as set focus directly to the
error message. Links then provide direct access to the relevant form
fields, also with visual highlighting and focus set. It works well,
even with javascript disabled.
If anyone has feedback about this approach, please post it. I'm
working on packaging up the script and PHP code for others to use, but
want to make sure it works correctly.
Jared Smith
WebAIM.org
From: tedd
Date: Thu, Apr 19 2007 8:50AM
Subject: Re: Focus for error messages
← Previous message | Next message →
At 8:32 AM -0600 4/19/07, Jared Smith wrote:
>On 4/19/07, Karl Groves wrote:
>
>> Does anyone have any good examples of methods to supply error messages as
>> they occur that are accessible?
>
>We implemented a method that seems to work pretty well. It doesn't do
>it 'live', but after the form is submitted. You can try it out at
>http://webaim.org/contact/ (just leave a field blank, no worries if
>you accidentally send a message). It uses javascript to visually
>highlight the error messages as well as set focus directly to the
>error message. Links then provide direct access to the relevant form
>fields, also with visual highlighting and focus set. It works well,
>even with javascript disabled.
>
>If anyone has feedback about this approach, please post it. I'm
>working on packaging up the script and PHP code for others to use, but
>want to make sure it works correctly.
>
>Jared Smith
>WebAIM.org
Jared:
It doesn't check for a valid email address.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
From: tedd
Date: Thu, Apr 19 2007 9:00AM
Subject: Re: Focus for error messages
← Previous message | Next message →
At 2:56 PM +0100 4/19/07, Joshue O Connor wrote:
>JAWS in forms mode is actually JAWS interacting directly with the web
>interface/application itself. Otherwise the screen reader is interacting
>with a virtual version of the page via the OSM (Off Screen Model). Many
>screen readers use these methods and some interact directly through the
>DOM such as Supernova/HAL.
>
>tedd said:
>> you use a new window to show error messages, then that will be
>>provided to screen readers.
>
>Thats one way but this may not always be ideal. Also, if the DOM is
>being manipulated then these error messages may not be displayed at all
>as the page is not refreshed when dynamically manipulating the DOM. You
>may be able to trigger page refresh etc but I suppose this goes against
>the grain of dynamically generating content on the fly a la AJAX.
>
>> if you initiate a screen refresh of the current window, then
>>whatever errors that are new on that page (via ajax) will be made
>>accessible to screen readers as well.
>
>Could you please expand a little on how you suggest that will work?
I may be totally "out to lunch" on this, but in one of my experiments
writing an audio captcha, my blind testers reported that when a
screen refresh was initiated, their screen readers re-read
everything. So if something has been ajax'ed to the screen, then
would it not be read if a screen reader reads the page again?
I know this goes against the DOM manipulation thing, but that's the
problem screen readers have with ajax in the first place, right?
Also, another idea came to mind as I was typing this and that was to
use iframes. I think that iframes may cause screen readers to read
that portion of the new presentation (i.e., errors) without
re-reading the entire page again. I know it worked for me in my audio
captcha, please review this:
http://sperling.com/examples/captcha/
I use iframes to deliver the audio portion of the captcha. Perhaps
that may be a vehicle to deliver error messages.
Boy, I sure wish I could make living working on stuff like this --
there is so much opportunity to plug these holes.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
From: Joshue O Connor
Date: Thu, Apr 19 2007 9:20AM
Subject: Re: Focus for error messages
← Previous message | Next message →
Hi Tedd,
> I may be totally "out to lunch" on this, but in one of my experiments writing an audio captcha,
>my blind testers reported that when a screen refresh was initiated, their screen readers re-read everything.
>So if something has been ajax'ed to the screen, then would it not be read if a screen reader reads the page again?
I do know that having to re-read an entire page (which could contain a
lot of content) is not in principle a good way for users to discover
that there is an error. A sighted user can obviously quickly scan the
page but a non sighted person relying on a linear output device like a
screen reader will pretty much have their head wrecked sharpish, to use
the technical terms :)
> So if
>> something has been ajax'ed to the screen, then would it not be read if a
>> screen reader reads the page again?
If there has been a page refresh and the user then chooses to give the
field focus again then yes.
I will have a look at your audio captcha, thanks for posting the link.
> I use iframes to deliver the audio portion of the captcha. Perhaps that may be a vehicle to deliver error messages.
You are maybe using iframes because to their ability to receive focus,
but you could probably achieve the same effect by using an anchor/link
AFAIK wrapped in a positioned div.
Cheers
Josh
********************************************************************
NOTICE: The information contained in this email and any attachments
is confidential and may be privileged. If you are not the intended
recipient you should not use, disclose, distribute or copy any of
the content of it or of any attachment; you are requested to notify
the sender immediately of your receipt of the email and then to
delete it and any attachments from your system.
NCBI endeavours to ensure that emails and any attachments generated
by its staff are free from viruses or other contaminants. However,
it cannot accept any responsibility for any such which are
transmitted. We therefore recommend you scan all attachments.
Please note that the statements and views expressed in this email
and any attachments are those of the author and do not necessarily
represent the views of NCBI
********************************************************************
From: Rich Pedley
Date: Thu, Apr 19 2007 12:40PM
Subject: Re: Focus for error messages
← Previous message | Next message →
On 19/04/2007 14:55, Tim Harshbarger wrote:
> Rich,
>
> If displaying the errors causes the page to refresh, JAWS should revert
> to virtual cursor mode unless the user has specifically altered the
> settings that cause JAWS to turn off forms mode on a page refresh.
So interspersing text within a form is still a no no then? I have
always assumed so myself, and tend to list errors at the top of the
page *before* the form.
> I am uncertain what the other screen readers do.
Catering for all of them would be a nightmare anyway, especially when
you consider that most of them, JAWS included, are still lacking in a
lot of ways.
Rich
From: Rich Pedley
Date: Thu, Apr 19 2007 12:50PM
Subject: Re: Focus for error messages
← Previous message | Next message →
On 19/04/2007 15:32, Jared Smith wrote:
> We implemented a method that seems to work pretty well. It doesn't
> do it 'live', but after the form is submitted. You can try it out
> at http://webaim.org/contact/ (just leave a field blank, no worries
> if you accidentally send a message). It uses javascript to visually
> highlight the error messages as well as set focus directly to the
> error message. Links then provide direct access to the relevant
> form fields, also with visual highlighting and focus set. It works
> well, even with javascript disabled.
>
> If anyone has feedback about this approach, please post it. I'm
> working on packaging up the script and PHP code for others to use,
> but want to make sure it works correctly.
Looks good, but could perhaps be improved. Currently on an error the
link provided goes directly to the input, Where as it would be better
going to the label. This may not be the best for accessibility, but
usability wise I feel it is better. *I* get confused when the label
for the relevant input isn't on the screen!!
Of course it could just be me, I'm usually slightly off beat with
these things :grin:
Rich
From: tedd
Date: Thu, Apr 19 2007 2:10PM
Subject: Re: Focus for error messages
← Previous message | Next message →
At 4:16 PM +0100 4/19/07, Joshue O Connor wrote:
>Hi Tedd,
>
>> I may be totally "out to lunch" on this, but in one of my
>>experiments writing an audio captcha,
> >my blind testers reported that when a screen refresh was
>initiated, their screen readers re-read everything.
>>So if something has been ajax'ed to the screen, then would it not
>>be read if a screen reader reads the page again?
>
>I do know that having to re-read an entire page (which could contain a
>lot of content) is not in principle a good way for users to discover
>that there is an error. A sighted user can obviously quickly scan the
>page but a non sighted person relying on a linear output device like a
>screen reader will pretty much have their head wrecked sharpish, to use
>the technical terms :)
I can realize that. I was just saying that my understanding was that
JAWS requires a refresh to present the user with something new.
Is a javascript solution using pop-ups OK, or not? If it is, then js
can evaluate each text field while, or after, the user enters
something and then create a pop-up to tell the user if there is an
error. However, I don't know how JAWS works with pop-ups.
If js is not an option, then a "behind the scenes evaluation" of the
data entered can certainly be done with php which could generate a
window telling the user what was wrong. After which, the original
window could be reopened with all the fields being sticky (i.e.,
containing all the entires except for the error field) with focus on
the field that generated the error. I'm sure I could do that. Would
that work?
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
From: Emma Duke-Williams
Date: Thu, Apr 19 2007 2:40PM
Subject: Re: Focus for error messages
← Previous message | Next message →
On 19/04/07, Rich Pedley < = EMAIL ADDRESS REMOVED = > wrote:
> Looks good, but could perhaps be improved. Currently on an error the
> link provided goes directly to the input, Where as it would be better
> going to the label. This may not be the best for accessibility, but
> usability wise I feel it is better. *I* get confused when the label
> for the relevant input isn't on the screen!!
What's even worse, is when it tells you there's an error with the
form, but not where, or, it tells you where, but you can't figure out
what the error is ...
My surname sometimes triggers errors. Some sites don't like
double-barrelled names; other sites just give errors with no apparent
reason & the only way I've got round it is moving from Firefox to IE,
entering the *same* data - and it works.
Grrrr...
Emma
(and don't talk to me about flight booking forms that when you want to
change one detail, promptly forget everything you just told it.)
--
Blog: http://www.tech.port.ac.uk/staffweb/duke-wie/blog/
From: Keith Parks
Date: Thu, Apr 19 2007 2:50PM
Subject: Re: Focus for error messages
← Previous message | Next message →
On Apr 19, 2007, at 1:07 PM, tedd wrote:
> Is a javascript solution using pop-ups OK, or not? If it is, then js
> can evaluate each text field while, or after, the user enters
> something and then create a pop-up to tell the user if there is an
> error. However, I don't know how JAWS works with pop-ups.
Just to expand that question, does anyone know how screen readers
deal with system-level ALERT boxes?
In trying to address the "time out notification" requirement of 508
(p), we went with a message in an ALERT box, as opposed to a browser
window pop-up, which is what I assume people are talking about in
this thread.
Given the level of pop-up blocking users frequently have in force, it
seemed like the most reliable way to get the notice to display. Plus
I assumed that screen readers would have some mechanism to deal with
system-level messages like that.
Did I assume wrong?
******************************
Keith Parks
Graphic Designer/Web Designer
Student Affairs Communications Services
San Diego State University
San Diego, CA 92182-7444
(619) 594-1046
mailto: = EMAIL ADDRESS REMOVED =
http://www.sdsu.edu
http://www.sa.sdsu.edu/communications
----------------------------------------------------------
(Objects on your screen may be closer than they appear)
From: tedd
Date: Thu, Apr 19 2007 3:50PM
Subject: Re: Focus for error messages
← Previous message | Next message →
At 9:30 PM +0100 4/19/07, Emma Duke-Williams wrote:
>On 19/04/07, Rich Pedley < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Looks good, but could perhaps be improved. Currently on an error the
>> link provided goes directly to the input, Where as it would be better
>> going to the label. This may not be the best for accessibility, but
>> usability wise I feel it is better. *I* get confused when the label
>> for the relevant input isn't on the screen!!
>
>What's even worse, is when it tells you there's an error with the
>form, but not where, or, it tells you where, but you can't figure out
>what the error is ...
>My surname sometimes triggers errors. Some sites don't like
>double-barrelled names; other sites just give errors with no apparent
>reason & the only way I've got round it is moving from Firefox to IE,
>entering the *same* data - and it works.
>Grrrr...
>
>Emma
>(and don't talk to me about flight booking forms that when you want to
>change one detail, promptly forget everything you just told it.)
Three things:
First, my experience with FF is that the javascript has to be correct
whereas IE is a bit more forgiving.
Second, what you report about forms not remembering what you typed is
just poor form (pardon the pun). It's not hard to make forms sticky
(keep values), it just takes someone who knows what they're doing.
Third, likewise, to focus on the error and inform the user should not
be a problem -- this isn't rocket science. This is doable.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
From: Joshue O Connor
Date: Fri, Apr 20 2007 3:00AM
Subject: Re: Focus for error messages
← Previous message | Next message →
tedd wrote:
>> Is a javascript solution using pop-ups OK, or not?
Good question. What are others think about this approach, issues of
support for JS notwithstanding? My feeling is that it is not _always_
ideal. The error message will receive focus but there is potential for
the user to also miss it while concentrating on other JAWS output. You
should test it if you are a proficient using screen reader user (or user
test) and see if it works smoothly in each particular situation. I tend
to like the idea of having the errors as a list of links either above
the form itself or over the missed or incorrect form field. Each
situation can of course require a different approach so in some
situations the pop up may be OK.
> I don't know how JAWS works with pop-ups.
JAWS will see the pop up but again there is potential for it to be
missed as with any reader using the OSM the user is often interacting
with a virtualized page and not the page proper.
> a "behind the scenes evaluation" of the data entered can certainly be done with php which could generate a window telling the user what was wrong.
Even with one window it could get messy as the user may not know how to
get back to the main page. You could force focus for the window using JS
on each error instance but I guess it may be better to present the error
message near where the error occurs.
Cheers
Josh
********************************************************************
NOTICE: The information contained in this email and any attachments
is confidential and may be privileged. If you are not the intended
recipient you should not use, disclose, distribute or copy any of
the content of it or of any attachment; you are requested to notify
the sender immediately of your receipt of the email and then to
delete it and any attachments from your system.
NCBI endeavours to ensure that emails and any attachments generated
by its staff are free from viruses or other contaminants. However,
it cannot accept any responsibility for any such which are
transmitted. We therefore recommend you scan all attachments.
Please note that the statements and views expressed in this email
and any attachments are those of the author and do not necessarily
represent the views of NCBI
********************************************************************
From: tedd
Date: Fri, Apr 20 2007 10:30AM
Subject: Re: Focus for error messages
← Previous message | No next message
At 9:57 AM +0100 4/20/07, Joshue O Connor wrote:
>tedd wrote:
>>> Is a javascript solution using pop-ups OK, or not?
>
>Good question. What are others think about this approach, issues of
>support for JS notwithstanding? My feeling is that it is not _always_
>ideal. The error message will receive focus but there is potential for
>the user to also miss it while concentrating on other JAWS output. You
>should test it if you are a proficient using screen reader user (or user
>test) and see if it works smoothly in each particular situation. I tend
>to like the idea of having the errors as a list of links either above
>the form itself or over the missed or incorrect form field. Each
>situation can of course require a different approach so in some
>situations the pop up may be OK.
>
>> I don't know how JAWS works with pop-ups.
>
>JAWS will see the pop up but again there is potential for it to be
>missed as with any reader using the OSM the user is often interacting
>with a virtualized page and not the page proper.
>
>> a "behind the scenes evaluation" of the data entered can certainly
>>be done with php which could generate a window telling the user
>>what was wrong.
>
>Even with one window it could get messy as the user may not know how to
>get back to the main page. You could force focus for the window using JS
>on each error instance but I guess it may be better to present the error
>message near where the error occurs.
>
>Cheers
>
>Josh
Josh:
The only problem I have in attempting to solve problems like this is
that I don't have direct access to JAWS -- I can only guess at what
happens. So, I'm blind in a different manner.
However, I am positive that if I could fully understand what's
needed, then I could create a solution and I am certainly not alone
-- these are simple problems with simple solutions.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com