WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: [EXTERNAL]JAWS / says "No clickable elements on page"

for

From: Tim Harshbarger
Date: Jun 11, 2018 6:50AM


Hmm, there seem to be a lot of things added to the button that look to be for accessibility that I think might be totally unnecessary.

So, to make a button with a text label that is accessible, here is what is required:
<button>OMC Navigation</button>
If the button is disabled, you would change it to this:
<button disabled>OMC Navigation</button>

If the button is labelled using an image, this is how it would change:
<button><img src="image.png" alt="OMC Navigation"></button>
<button disabled><img src="image.png" alt="OMC Navigation"></button>

If you were labelling the button with a background CSS image, it would change a bit more:
<button aria-label="OMC Navigation" class="icon"></button>
<button disabled aria-label="OMC Navigation" class="icon"></button>

The code you provided includes a div, span, and some text. The above examples would remain the same except with the div, span, and text--instead of just text.
<button><div><span>OMC Navigation</span></div></button>

Things like role="button", tabindex="0", and aria-labelledby are not needed if you are using native HTML form elements like button, input, textarea, select, a, or area. Those elements already convey their role and states and will work using the keyboard. Typically, the only thing you have to do is ensure that they have labels (or an accessible name) which HTML provides ways to do.

Aria-labelledby is only necessary when the label for the widget isn't contained by the widget, but appears somewhere else on the screen--though often in those situations you would use a label element instead. For example:
<label for="userID">User ID:</label><input type="text" id=userID">
Rather than:
<span id="userIDLabel">User ID</span><input type="text" aria-labelledby="userIDLabel">
The majority of the time you would use the label element since it also increases the click area for the widget--that is clicking on both the label or the textfield brings focus to the textfield. However, sometimes you will run into situations where aria-labelledby is the only way to resolve the problem. You then use aria-label in those situations where the other methods won't work---like in the situation where you need to label a button that is using a CSS background label or icon as the label.

It looks like you are using the button to create a hamburger menu, if that is so you will probably want to look at the WAI-ARIA 1.1 design pattern for menu buttons:
http://www.w3.org/TR/wai-aria-practices-1.1/#menubutton

One advantage of using the design pattern is whoever is testing with JAWS can just focus on ensuring the widget works like the design pattern states. That mainly involves ensuring all the keyboard commands work and ensuring that the role and state information is being conveyed by the screen reader.

I hope that helps.

Thanks,
Tim
-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Lawrence Guros
Sent: Friday, June 8, 2018 2:15 PM
To: <EMAIL REMOVED>
Subject: [EXTERNAL] Re: [WebAIM] JAWS / says "No clickable elements on page"

OK, here is an HTML example button created with our Knockout based
single page infrastructure. This is back to Client-Server technology,
with the client written in Javascript and javascript based technologies.

In many cases, we do not have direct access to modifying the HTML directly.

We do have accessibility toolbars build into a browser that test many
things, including color contrast, HTML, alt-text, aria-labels, ids...
Keyboard testing showed only a few issues that were fixed, so we can
access anything in the page from the keyboard, including popups and the
like.

I should also state, that our test person is just starting out in JAWS,
and I am not sure if he was in "Virtual Cursor Mode". I have asked. He
is able to navigate the page using tabs in JAWS. (We are only doing the
screenreader testing with JAWS). I am pretty much a neophyte with screen
readers, just a developer that wants to make sure it is done right.

I will check if there is a page on the open internet that can be
accessed for free.

Here is a sample of a button that was grabbed from Chrome. I would
expect the "click" data-binding would result in a javascript
element.addEventListener() to catch the click. In Chrome, there are
click event listeners listed, but not as attributes. Looks like JQuery
may be involved, as there are some event handlers in some Jquery
attributes.  Will have to dig more.

<button id="hamburgerButton" class="emaas-appheader-hamburger-button
emaas-appheader-toolbar-button oj-button-jqui oj-button oj-component
oj-enabled oj-default oj-button-half-chrome oj-button-icon-only
oj-component-initnode" data-bind="ojComponent: {component:'ojButton',
display:'icons', chroming: 'half',
                                label: hamburgerBtnLabel, disabled:
!renderHamburgerMenu,
                                icons: {start: 'fa-icon-font fa-bars'}},
                    click: renderHamburgerMenu ? toggleHamburgerMenu :
null, attr: {title: hamburgerBtnLabel}" role="button" tabindex="0"
aria-labelledby="ui-id-1" title="OMC Navigation"><div
class="oj-button-label"><span class="oj-button-icon oj-start
fa-icon-font fa-bars"></span><span class="oj-button-text
oj-helper-hidden-accessible" id="ui-id-1">OMC
Navigation</span></div></button>

Thanks for the responses!
Larry

Subject:
Re: [WebAIM] JAWS / says "No clickable elements on page"

From:
"Patrick H. Lauke" < <EMAIL REMOVED> >
Date:
6/7/2018 3:23 PM

To:
<EMAIL REMOVED>


On 07/06/2018 18:35, Lawrence Guros wrote:
> JAWS / says "No clickable element on page" - Does anyone know what
> JAWS considers a clickable element? There are many buttons, etc on the
> page. We do use Knockout, so I think most of the event listeners are
> probably (speculating here) done with javascript
> element.addEventListener and not by having a click="someFunction()" in
> the DOM. Is that the issue? (but not under our control).
>
> Is this an accessibility issue?

For reference: without providing a reduced test case, a live URL, or
even just an extract of the markup/DOM, it's always difficult to
diagnose this sort of thing.

Also...just JAWS? Which browser? Have you tried other browser/AT
combinations? Do they all report things the way you expect, and it's
only JAWS that's misbehaving?

P
--
Patrick H. Lauke

twitter: @patrick_h_lauke | skype: patrick_h_lauke


Re: [WebAIM] JAWS / says "No clickable elements on page".eml

Subject:
Re: [WebAIM] JAWS / says "No clickable elements on page"
From:
Tim Harshbarger < <EMAIL REMOVED> >
Date:
6/7/2018 3:34 PM

To:
WebAIM Discussion List < <EMAIL REMOVED> >


When is JAWS giving you the "no clickable elements" message. Are you using the / (slash) hot key in virtual cursor mode?



If you are testing with JAWS you will want to use other keys to navigate and use the page. I think the only time I have ever used that keystroke myself is I need to find a page element that isn't one of the HTML 5 interactive elements (like links) or an element provided with an aria role and a tabindex. Basically a situation where someone attached a click event to an element and didn't do any of the other things that would make it accessible.



Thanks,

Tim







-----Original Message-----

From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Steve Green

Sent: Thursday, June 7, 2018 1:19 PM

To: WebAIM Discussion List< <EMAIL REMOVED> >

Subject: [EXTERNAL] Re: [WebAIM] JAWS / says "No clickable elements on page"



This sounds like a massive accessibility issue, and not only for screen reader users. JAWS considers clickable elements to be links, buttons and elements with onClick event handlers - I don't think there's anything else.



I have encountered many websites where JAWS does not recognise one or more of the links or buttons, but never a website where it didn't recognise any. In the case of links, the cause is often the absence of an "href" attribute, which would also break keyboard navigability. In that case, adding href="javascript:void()" or href="#" usually fixes the issue.



Steve Green

Managing Director

Test Partners Ltd