onclick event and screen readers

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

onclick event and screen readers

mozilla accessibility
OK, this is maddening!

I thought I understood how onclicks worked, but maybe not.  I just coded a
very simple page with inline onclicks on a span and an anchor. They simply
fire an alert.  The span has a tabindex of zero.

With Jaws enabled, things work as expected when using the keyboard, except
that the span is not spoken (jaws9), or the text of the anchor is spoken
instead of the text of the span (jaws8).  These seem to be long standing
Jaws bugs.

However, with no screen reader enabled, the onclicks do not fire at all with
the keyboard.  Is this correct behavior? I thought that onclick was a
generic event which would fire when the mouse was clicked or the
platform-specific keyboard activation keys were pressed (on windows, space
or enter should do the trick). This is all true if Jaws is enabled.

Firefox doesn't draw the focus when it moves to the span; at least IE does
this correctly.

Can anyone else confirm this behavior?

Thanx in advance.
-- Rich

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility

t.html (402 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: onclick event and screen readers

Aaron Leventhal-3
Hi Rich.

If you put an href on the <a> I believe things will work as you're
expecting. You might use href="#". I'm not sure if href="" will work.
The enter key should act as a click in that case, and focus will show.
The <a> will also look like a link.

For the span, you need to handle the onkeydown for the Enter key. There
is no conversion of Enter to a click for generic elements. I'm not sure
whether there should be or not. No doubt it would save some code, but
I'm not sure if that would work across browsers. We had a bug open to
discuss it at one point.

- Aaron
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: onclick event and screen readers

Matt Morgan-May
Hi,

The UAAG test suite has at least a couple of tests for this. The best
practice, as far as I can recall, is to allow generic elements to accept
keyboard focus, and for Enter to trigger the click event. (As far as a
double-click event goes, you're on your own. :)

http://www.w3.org/WAI/UA/TS/html401/cp0102/0102-ONCLICK.html
http://www.w3.org/WAI/UA/TS/html401/cp0102/0102-ONCLICK-MULTIPLE-EVENTS.html

-
m

On 3/7/08 2:05 PM, "Aaron Leventhal" <[hidden email]> wrote:

> There
> is no conversion of Enter to a click for generic elements. I'm not sure
> whether there should be or not. No doubt it would save some code, but
> I'm not sure if that would work across browsers.

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: onclick event and screen readers

mozilla accessibility
In reply to this post by Aaron Leventhal-3
The problem with putting the href on the link is that the page then
"refreshes". Is there a way of causing the link not to refresh when it has
href?

Thanx.
-- Rich

----- Original Message -----
From: "Aaron Leventhal" <[hidden email]>
Newsgroups: mozilla.dev.accessibility
To: <[hidden email]>
Sent: Friday, March 07, 2008 5:05 PM
Subject: Re: onclick event and screen readers


Hi Rich.

If you put an href on the <a> I believe things will work as you're
expecting. You might use href="#". I'm not sure if href="" will work.
The enter key should act as a click in that case, and focus will show.
The <a> will also look like a link.

For the span, you need to handle the onkeydown for the Enter key. There
is no conversion of Enter to a click for generic elements. I'm not sure
whether there should be or not. No doubt it would save some code, but
I'm not sure if that would work across browsers. We had a bug open to
discuss it at one point.

- Aaron
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: onclick event and screen readers

Hans Hillen-3
In reply to this post by Aaron Leventhal-3
For a link to be properly focusable and clickable, it needs an href value.

If you don't want the page to refresh, you must have your event handler have return false whenever it's called. This
will prevent the default action (in this case loading the page the link points to). In the example below, the link
originally points to a different page which would inform the user Javascript must be enabled. However, if Javascript
does work, it will cancel this page from being loaded by returning false.

Example 1 start

HTML:

<a href="nojavascirptwarning.html" onclick="return showAlert('alright, you clicked me')">Click me</a>

JavaScript:

function showAlert (msg) {
    alert(message);
    return false;
}
       
Example 1 end

The support for the enter key with regards to click events is only present for controls that are clickable by default,
such as links and form controls. For anything else, such as divs and spans, you will have to manually assign both an
onclick handler as well as key handler that checks if the enter or space key was pressed.

Also be aware that using spans and divs rather than links, you won't have the guarantee that assistive tech will
announce it as an interactive control (although JAWS obviously does by saying 'clickable') regardless of whether the
tabindex is set. The user might not realize that the control is actually interactive. Therefore you should only use this
technique if you combine it with ARIA, which will tell the screen reader what kind of control the span is trying to
impersonate.

As for the visual indication of focus: It's actually the other way around: Firefox gets it right, I.E. doesn't draw
focus for elements that are not natively focusable by default when you use a tabindex value of -1 (but it does for a
tabindex of 0). Firefox (like other standard compliant browsers) also lets you easily create styles to create a more
noticeable (e.g. high contrast) indication of focus using CSS. The example below shows CSS code which causes every span
element with a class of 'myControl' to get a black background and yellow letters when they receive focus, making focus
easily noticeable.

Example 2 start:

span.myControl:focus {
        background-color: #000000;
        color: #FFFF00;
}

Example 2 end

However, since IE does not support the :focus pseudo class, and does not allow the :active pseudoclass to be used like
it does for natively focusable controls, you will have to define onfocus and onblur event handlers, which will
dynamically add and remove the styles when the element gains or loses focus.

Hope this helps,

Hans

Rich Caloggero wrote:

> The problem with putting the href on the link is that the page then
> "refreshes". Is there a way of causing the link not to refresh when it has
> href?
>
> Thanx.
> -- Rich
>
> ----- Original Message -----
> From: "Aaron Leventhal" <[hidden email]>
> Newsgroups: mozilla.dev.accessibility
> To: <[hidden email]>
> Sent: Friday, March 07, 2008 5:05 PM
> Subject: Re: onclick event and screen readers
>
>
> Hi Rich.
>
> If you put an href on the <a> I believe things will work as you're
> expecting. You might use href="#". I'm not sure if href="" will work.
> The enter key should act as a click in that case, and focus will show.
> The <a> will also look like a link.
>
> For the span, you need to handle the onkeydown for the Enter key. There
> is no conversion of Enter to a click for generic elements. I'm not sure
> whether there should be or not. No doubt it would save some code, but
> I'm not sure if that would work across browsers. We had a bug open to
> discuss it at one point.
>
> - Aaron
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility
>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: onclick event and screen readers

Aaron Leventhal-3
In reply to this post by mozilla accessibility
Matt Morgan-May wrote:
<snip>
> The best
> practice, as far as I can recall, is to allow generic elements to accept
> keyboard focus, and for Enter to trigger the click event.

Seems like a good idea to me, but Opera is the only browser I can find
that does that. Is there a best practice doc?

- Aaron
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility