I'm working on a website that has to be accessible for almost anyone.
Currently, I'm trying to figure out a way to make checkboxes accessible by different types of screen readers, using the keyboard to navigate through the content. At the moment i'm using both the standard Windows Screenreader and NVDA (see https://www.nvaccess.org/). I've tried different solutions I found on the web, but i'm still stuck and I would love some tips and trix on how to implement these sorts of features. One thing to note is that it has to work for different types of browsers (ideal would be Microsoft Edge, Google Chrome and Internet Explorer).
The ideal scenario would be something like this:
1: Navigate to the checkbox (or list off checkboxes) using the tab key.
2: The screen reader informs me that it's a checkbox, it's current state (checked, not checked), and its label.
3: Space key will uncheck and check my checkbox, informing me of my actions.
Here's two different code snippets that I've tried, but they only work on Microsoft Edge and Internet Explorer:
<fieldset id="accept">
<legend> My legend </legend>
<input type ="checkbox" id ="chbox" name ="check_1">
<label for "chbox">This is my checkbox></label>
</fieldset>
And this is when i'm using the Struts checkbox tag.
<span class="">
<s:checkbox
label="someLabel"
name="someName" id="accept" />
</span>
These work as expected in Microsoft Edge and Internet Explorer, but whenever I'm using Google Chrome, the screen readers are having trouble figuring out my content. The scenario I'm having:
1: I'm tabbing to my Checkbox, the screen readers say "Tab".
2: I'm using the space key to uncheck my checkbox, the screen readers
say "Space". (It still unchecks my checkbox though)
Apart from this, I've tried to surround my code in different divs, assigning roles and web-aria, but nothing seems to work. As I'm totally new to this, I would love some 'best-practice' ideas and tips.
Any help is appreciated,
Thanks in advance.
First, I could suggest you not to use Struts checkbox as most of them are design for legacy browser. And it may not always best for modern screen reader.
Regarding the checkbox, the recent recommendations from ARIA reference is to use DOM structure <label><input>Text</label> over <label for>.
Or use aria-label on the checkbox. But the second way is less recommend due to different support from browser/screen reader. In some bad case, they could ignore or read duplicate by different way to read the line.
Well, it's kind of a Chrome Issue.
Check this as you're not the only one.
I don't know any solution for this, I've bumped into this a few years back, luckly I just had to make it at A/AA.
It's worth mentioning that Narrator does not support third party (non-Microsoft) browsers.
Related
Perhaps I've been searching for the wrong thing but I've not been able to find a solution of how to either style or disable the default way that browsers on iOS handle <select>. I know when you're actually developing for iOS applications it's called a UIPickerView. Whenever I search for this I always get links to app development help.
Is any one aware of a way to handle this?
The problem that we are having is that our security questions, on our form, are too long to see.
Note: The screen shot is not of our site. I was just trying to provide an image of that to which I was referring.
I have some information in HTML run in a WebView on an iPhone which should not be visible to regular Users, but should be read out by accesibility features such as IOs's VoiceOver.
just putting all the information inside an aria-label="lorem ipsum dolor" attribute did not work. Voice Over stil reads out the plain content of the tag. So i tried adding an "invisible" Element holding this information. However it seem to me that VoiceOver magically ignores elements which are not visibleto the user. I tried the varios techniques described by the Yahoo Accesibility Lab: http://www.cssmojo.com/hide-content-from-sighted-users/ but none of them are working for me.
Here is the Code:
<div tabindex="2">
<h2 class="visually-hidden">Ausgewählter Ton:</h2>
<div class="jingle" ng-if="ctrl.getAlarmJingle()">{{ctrl.getAlarmJingle()}}</div>
</div>
I want VoiceOver to read out "Ausgewählter Ton:" plus the value of `{{ctrl.getAlarmJingle()}}. best case would be that all of this appears to be one element in VoiceOver the Accessibility-Tree. What is the best practice of doing this? Has anybody good resources on how VoiceOver really works?
The Project is a hybrid app using angular 1 and Ionic. We are using wkwebview as WebView, but i don't think thats relevant for VoiceOver problems.
Sorry the problem was, that my scss wasn't compiled hance the css never updated. Now that it does everythings works as expected.
I'm working on a web page for a project and currently we are using a table to control the layout of content.When a screen reader (I'm testing with NVDA) focuses on the first item in the table, it speaks "Table with 7 rows and 3 columns" and then reads the item.
<table role="presentation">
<tr>
<td tabindex="0" class="bold">Item</td>
</tr>
</table>
Is there a way to prevent the screen reader from speaking the table information? I've tried setting the role to presentation and it still speaks it. I know using tables as a means of designing layout is bad practice, but this is for a prototype.
Thanks
Providing a URL would allow us to test it to hear what you hear. Telling us what version of NVDA you are using would help. Knowing the browser you are using is also hugely important as they expose different things through their accessibility APIs. So please provide the following:
URL for testing,
The version of NVDA you are using,
The web browser you are using with NVDA.
As for compatibility expectations, there is a handy chart tracking issues (last updated in October 2016):
Layout table with role presentation: Screen reader compatibility
Per that site it should perform well for these combinations:
Good: NVDA with IE Stable - OK from NVDA 2014.1 to NVDA 2016.2
Good: NVDA with FF Stable - OK from NVDA 2014.1 to NVDA 2016.2
Also, I see tabindex on the cell. A screen reader user does not need it to get to the content. When you remove it, does NVDA behave?
Two overall recommendations:
Do not use tables for layout, even for prototyping;
Remove the tabindex from everything unless you are also adding all the necessary roles and keyboard interaction to truly make it an interactive control.
There are 2 ways I know of:
This will make it invisible to nvda:
aria-hidden = true
This makes the element not focusable:
Tab-Index="-1"
I am working on developing/testing accessibility of a web page using VoiceOver [Mac Tool].
Typical workflow I am using is trial and error,
Do changes to HTML
Open page in browser
Turn on VoiceOver and test and again #1
What I understand is VoiceOver convert/see HTML/Webpage in text form and starts reading it. I hope how it does it would make it easy for me to understand how to make process easy.
So I want to know if there is any tool or utility or guidelines which could assist me to see HTML/Webpage the way VoiceOver does. I mean tool which take html as input and then output text file like VoiceOver (JUST to understand what changes affects VoiceOver in what way quickly).
Any inputs will be really helpful.
WebAIM has a great article titled Using VoiceOver to Evaluate Web Accessibility
It helps by telling you how to get set up, what keys are used, how users navigate, how to test images, tables, and other elements.
Testing with any screen reader is about more than tabbing through the page as you watch. Ideally you want to get to the point where you can turn off your screen and test. You must also recognize that most VO users do not tab through a page, but instead tend to jump around by landmarks, headings, links, lists, and so on.
I am not pasting the entire article, but here is the outline:
Introduction
Getting Started
Reading
Navigation
Other useful shortcut keys
Images
Data Tables
Forms
Practice
VoiceOver on the iPhone, iPod Touch, and iPad
Chrome Dev tools has an Accessibility Properties panel, which will show you the accessible name of an item the way it is exposed to the VoiceOver API. It would be quicker to keep that panel open and only test in VoiceOver when you are happy with what you're seeing in the panel.
To answer your question, it sounds like you're looking for the Accessibility inspector tool, which exposes the accessibility API (OSX Safari uses NSAccessibility and iOS Safari uses UIAccessibility for iOS) bits (which VoiceOver consumes). This is part of Xcode, so you'll need Xcode on your Mac to get to it
I have been told by my boss to add tabindex="1" to the Accessibility link in our site footer so that it will be the first thing that someone who browses a site by keyboard can get to and read about the accessibility steps we take.
I have added tabindex="1" to the link which you can see here, but the browser doesn't seem to respect it at all (tested in Chrome/FF/IE 11). There are no other tabindex attributes on the page that I can see, so surely it should get picked up as the priority by the browser.
There are access keys used on the page, could this throw it out in some way?
I am sure it is something really fundamental, but I can't see what it is. Any help would be appreciated.
Thanks
It works for me, but as a long-time accessibility advocate I'd like to help persuade your boss it's a bad idea.
To see it working I suspect you are on a Mac and you need to enable keyboard navigation. People who need that would typically have it on already.
However, the reasons that adding a positive tabindex are not helpful include:
Someone using a keyboard (or keyboard equivalent device) and can see the screen will be confused. They press tab and suddenly end up at the bottom of the page, then flip back up to the top. Combined with the lack of focus visibility, this will be very difficult to cope with.
Someone using a screenreader will probably not notice the tabindex to start with because the main way of navigating is with 'arrowing' (using up/down to go element by element). However, if they are in the content area and press tab to skip to the next link or form control, they will suddenly go to the bottom of the page. Very confusing.
So in summary: Adding a positive tab index on a link in the footer will negatively impact the people it is supposed to help.
Here are the appropriate ways to use tabindex.
There are quite a lot of obvious accessibility issues on the site, I'd recommend getting some advice.