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"
Related
I been doing some research but I having issues finding a good way to test my Aria-labels, and other Aria tags I used. What is the best practice for testing this. Currently doing this for Angular using Material UI which already has some good ARIA support.
I tried using the trial version of JAWS 9 but sometimes I can't tell if it's my code is bad or the screenreader isn't as good as I hope.
Thanks for reading and hope someone could point me in the right direction.
JAWS has been around for a long time so if things are not working like you'd expect, sorry to say, it's probably a problem with your code. However, JAWS isn't great for testing because the intent of JAWS is to allow visually impaired users to get stuff done on their computer. JAWS uses some heuristics when it's reading a website and if you have bad html, JAWS will try to figure out what you meant so that the end user can finish their task.
NVDA is a great a screen reader for testing. It will not try to guess what your code is doing and if you have poorly written html, it'll be read poorly. And it's free (although donations appreciated).
Both JAWS and NVDA are for the PC.
On a Mac, you can use the built in VoiceOver screen reader. Nothing to install. Just hit Cmd+F5.
Turn the screen reader on and navigate through your site using tab and listen for how interactive elements are announced. You can turn on NVDA's speech viewer tool (ins+n > tools > speech viewer) and you can see what is being spoken. VoiceOver has a "closed captions" type viewer so you can see what's being announced. Your aria-labels will be read by the screen reader.
You can also use the shortcut keys when NVDA is running to see if other elements are defined properly.
H - navigate to the next heading
B - navigate to the next button
T - navigate to the next table
L - navigate to the next list
See https://www.nvaccess.org/files/nvda/documentation/userGuide.html#SingleLetterNavigation
Chrome devtools has build in accessibility check:
Press F12 (or just open your Chrome devtools)
Choose the tab "Elements"
Click on the tag you want to inspect
there has a part underneath where you can see all the styles for your tags, classes,...and it is calles "Styles"
here you can also choose between tabs, so choose then for "accessibility"
Now you are able to see which aria attributes are set for your tag.
(In this image you can see that I put an aria-hidden attribute on my font-awesome so screenreaders don't try to read the icon)
Chromevox is a good plugin for simulating screen reader if that's what you are looking for. If you're interested in learning how good your website is conforming to accessibility guidelines, you can go to the audits in chrome dev tools & run a report. (Ctrl+ Shift + I -->Audits --> Select only accessibility & hit Run audits)
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.
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
After adding accessibility to my HTML page, how would one test if it is working correctly? I would like to hear how it sounds and navigates for someone who is using a screen reader.
Let me put it another way, when you build a web page you preview it in a browser(s) to see if it looks and behaves correctly. When you add accessible to that same web page how to do you know it's working correctly?
If you are looking for a quick spot check, you can use WebAIM's WAVE, which tells you the big errors. If you wish to dig deeper, you both need an understanding of WCAG 2.0, and assistive technology. WebAIM has a checklist for WCAG 2.0, which would be the next step, along-side using assistive technology. People tend to only think assistive technology = screen readers, but this is incorrect. There are many different types of assistive technology. I recommend reading through the note at the top of the checklist.
NVDA is a free screen reader
Looks like you might be SOL:
Site accessibility: what screen readers, etc to test against, and how?
Screen Readers For Testing Website Accessibility
If you're really looking for a semi-automated solution, you might be able to stitch together Selenium (or similar) and a screen reader emulator (as described in the second linked post) to pull down an audio file of the screen reader, then submit the text to Mechanical Turk for transcription, then diff your site text against the transcript you get to see how confused the writer was. It would cost a few bucks, but potentially save you more-expensive programmer hours.
One of the projects I am currently working on has customer requirements for IE7 and 508 compliance. This customer currently uses JAWS version 9 and is making requests which I am told are impossible without a newer version of JAWS which supports WAI-ARIA. For example:
Accessible, 508 compliant Ajax Loading Indicator
Accessible, 508 compliant Ajax Pagination
Before I come back and tell them that they need to upgrade to a newer version of JAWS (from Freedom Scientific's website, WAI-ARIA is supported starting with version 10), I would like to be armed with as much information as possible to make a convincing argument. First of all, is IE7 capable of conveying ARIA information to JAWS (I've seen claims of ARIA support starting with IE8, but nothing explicitly stating it doesn't work with IE7)? If so, is it only to a limited extent? Supposing the answer to this question is yes and the degree of support is sufficient, are there big differences in support between JAWS versions 10, 11, and 12 which I should know about? Perhaps this will is a good bar to meet: given the requirement for IE7, what is the minimum version of JAWS required to apply ARIA in order to solve the two questions linked above.
I know there are a lot of questions jammed in here, but I believe they worked together as a single question: please give me an overview of the varying degrees of support for WAI-ARIA between IE7 and different versions of JAWS; and to what extent can these solve the customer requests linked above.
Thanks! And even if you can't address all of the elements of this question, I would be grateful for any information you can share.
You seem to be equating 508 compliance with support for WAI-ARIA? AFAIK 508 doesn't dictate the use of ARIA.
While ARIA has been designed to overcome the many difficulties of making dynamic web apps accessible, some old hacks that it's designed to replace still more or less work. Also because it is a relatively new technology there is limited support in anything but the latest browsers/Assistive tech.
To have an AJAX progress indicator and pagination accessible with-out ARIA is not straightforward but usually you can get it working one way or another by forcing Focus to the updated parts of the page and using hidden (off-left) text to give screen reader users some verbal directions or hints. The trick being this has to be done is such a way that JAWS will go back and reload it's DOM rather that it's cached version of the page. JAWS 9 is better at this than previous versions.
If you google around you should be able to find various ways to do this.
My adice to you is hire an Accessibility Consultant for a couple of sessions otherwise you are going to be stumbling around in the dark, they'll also be able help you talk to your client and suggest Design changes if it is all looking too complicated to be done in an accessible way.
"First of all, is IE7 capable of
conveying ARIA information to JAWS"..
etc
Browsers don't send ARIA information directly to JAWS, they notify the accessibility layer of Operating System which just interpret the messages as standard operating system accessibility messages. The Assistive technology (JAWS or whatever) are just (hopefully) listening for these system messages.
I can’t speak to Chris Bentley’s suggestion of using off screen text to provide hints to screen readers. While I assume this would work I’ve never seen it done on a website. I’ve also never dealt with internal apps designed to be 508 compliant and have next to no web development experience. I second Chris’ suggestion of hiring a consultant who has experience in this area. I don’t know what the differences are between Jaws versions and WAI-ARIA support. I know Jaws 10 does at least offer some WAI-ARIA support under Internet Explorer 7. I just went to http://news.yahoo.com with Jaws 10 and was able to use the ; key to move from landmark to landmark. You can run multiple versions of Jaws without a problem on the same machine, I currently have Jaws 10, 11, and 12 installed. This should allow you to test different versions of Jaws if you can't find documentation that spells out the differences.
WAI-ARIA support is available starting in IE8 and Firefox 2+. Concerning screenreaders, use NVDA instead of JAWS. It's free and works great with Firefox. In fact, the Mozilla foundation has granted funding to NVDA to improve the NVDA screen reader. They work great together.