Latest WebAIM screen reader survey released!

Accessibility
1

WebAIM: Screen Reader User Survey #3 Results

Some main points:

-JAWS (still most popular reader) is becoming less popular among those who take the surveys, while NVDA use has increased.
I wonder if the increase in VoiceOver is from the increasing popularity of iWhatevers (who all come with it pre-installed)

-IE is still the most popular browser among survey respondents.
(note from me: Some of the free readers, like Gnome Orca, only work with Firefox at the moment (webkit is being worked on).
I hope a good majority of the “Others” users are Opera users)

-The overwhelming majority of respondents have Javascript enabled (98.4%, and an increase from previous surveys).
This should pretty much put to rest the idea that screen readers can’t or don’t work with Javascript (it’s still just being run by the browser).

(note from me: What developers need to be careful with are widgets (like drag-n-drop sliders, calendars, etc) and content being dynamically added/ajax (ARIA attributes can help here). Scripts can interfere with a reader, and the user may not know how to turn Javascript off for that page (happened fairly recently on a mailing list where a script gave regular updates to a small scrollbox with calendar… the reader kept refreshing the page). Testing your scripts in a screen reader is a good idea if you can.)

-Mobile use is up significantly! Nokia is still the most popular (using Nuance as the reader for Symbian systems). About two-thirds use a mobile with screen reader regularly

-Respondents are generally optimistic about future accessibility of the web, though they don’t think much improved in the last year

-Respondents believe more accessible web sites, rather than better AT, would have the biggest impact on web accessibility

-While many respondents used social media sites (twitter, facebook, etc), the overall impression is that they are only somewhat accessible.
(me: I wonder if the variety of responses is affected by available plugins and specific features of these sites rather than the basic services.
(note for twitter users: there is Accessible Twitter : web accessibility for the Twitter.com website application, an app that uses the twitter API… very cool))

-While nearly half of the respondents didn’t know what to think of HTML5, those who were familiar with it were positive about it

-Awareness of ARIA landmarks has increased since the last study, but usage is uneven
(why?)

-Page navigation is increasingly relying on headers (h1-h6 tags).
To me, this suggests web pages are also using headers more than they used to (making the technique more useful than in the past).
Where the survey mentions “Find”, I don’t know if they mean a reader find function or the one built into the browser.

-There’s a slight decrease in the use of skip links since the previous survey. But in general usage is still spread around pretty good.
I still include skip links where appropriate, not so much for screen reader users, but for sighted keyboarders who may appreciate it.

-Some respondents try to find and use the mobile version of a site if one exists (generally those with less proficiency with their readers).
I recently saw this suggested on the Orca mailing list by an Orca user as a “tip”. I think this adds more fuel to the call by some web standardistas to rethink the complexity of the “desktop” versions of sites we build. The version for mobile is more likely to be a version that does everything users want it to, without the bloat.

-Text-only versions? Responses are mixed. Those with disabilities were more likely to use them than those without, but there was about 30% who rarely or never use them

-Two h1 tags, one for the site name and one for the particular page title, was most popular! If just one is available, users preferred the document/page name to be in the h1 rather than the site name (makes sense)
(from me: If your site name is in your <title> tag, that is the first thing announced when a page is being loaded. Google also looks at the <title>, so using an h1 for the site name on every page really has little value compared to the name of the actual page.)

-Longdesc, which was going to be removed from HTML5 (was not in the earlier specifications, but apparently is back in talks?) has most respondents being positive about it, with a large chunk not knowing much about it at all

Awesome study, keep them coming guys!

2

Nice summary, Stomme poes. Interesting to see VoiceOver gaining ground.

Are screen readers yet ready for the prospect of HTML5 allowing multiple H1’s on each page? That will be an interesting change.

3

Nothing legally prevents us from using multiple h1’s… the preferred 2 h1’s thing was on current websites (mostly HTML4-style) where basically people were marking up both the web site name and the page name in h1’s… that is, the two most important pieces of information both being in an h1, rather than one in an h1 and the other either not in a header or maybe in an h2. This survey might mean people find both of those parts of equal, and highest, importance, combined with header navigation (I confess it’s one of my main navigation tools too… just so easy).

The HTML5 multiple-h1 things is more like, an h1 heading each <section> rather than anything to do with a single page having two “titles”.

You can use a number to navigate to “the next h2” or whatever in a reader, so yeah, it’ll be interesting to see if something like an h1 per <section> with its own set of header levels is a pro or a con for screen reader users. It might not matter at all for pages where this setup is best, like a page (like BBC) listing a bunch of articles, each being in a <section> with their title being an h1… if your using header nagivation and not specifying which level header, you can just “h” your way through the whole list of articles, and use h2 to check the next header within that article for more skimming.

4

Yes, I guess not a lot is changing, as they are still headings. I still can’t see myself using multiple H1s any time soon. Funny how an idea gets in and is hard to shift. I was shocked when I first heard of the HTML5 structures.

5

That wasn’t the REASON for it, though that was often the effect it provided.

Headings exist to provide structure to a document – they should ‘fan out’ as lower level headings are by definition the start of subsections under the higher level heading preceeding it.

Because of this, having multiple H1’s is like having multiple trunks on a tree – it’s just not normal though it can happen. In a properly laid out document all h2’s should be the start of a subsection of content under the h1, h3’s are starts of subsections under the h2’s, etc, etc… It’s why skipping heading levels is poor coding, it’s why unless you are using 5 having more than one H1 makes no sense, and why on most sites there is no viable

Again, the newspaper comparison. Many people would make the largest headline on the front page the H1 and all the other headlines H2’s – which makes ABSOLUTELY NO SENSE as those other headlines are NOT subsections of the large headline, they are subsections of the paper AS IS that largest headline; they’re ALL H2’s structurally even if one of them is presented in larger text. It’s part of how many can’t seem to separate the meaning of a tag from it’s default appearance, and as most every document on the subject that’s worth a damn will tell you, you should never choose a tag based on how it looks when rendered.

But apparently this was “too complex” for most developers (who need to do us all a favor, back away from the keyboard and take up something less detail oriented like macramé weaving), which is why as part of their “let’s ressurect HTML 3.2 and pretend STRICT never existed” HTML5 nonsense they are adding the redundant “section” tag to basically do what heading tags were originally there to handle. People are apparently just too stupid to put things in the proper order no matter how many times you explain it to them.

But of course, nobody is going to bother to learn to do that properly either since everyone is too lazy and stupid do bother doing anything more than vomiting up markup any old way.

Back on topic, I found the bit about .skipto links interesting – SO many developers will try to tell you not to bother with those, but it’s like most of them have never owned/used a mobile device. It’s funny they mention heading navigation, as I always found that to be a fallback for when skipto links aren’t implemented properly. As an Opera mobile user (and Opera on the desktop) the sites that do support them are a joy to navigate; more-so when TITLE is included alongside ACCESSKEYS.

Though like anything else accessibility related, the more you layer in for choices the better the experience for everyone. Much less MOST of what gives you accessibility is no more or less work if you practice semantic markup, separation of presentation from content, SENSIBLE heading orders, and the dozen other good practices that should be a natural part of building a site.

6

Interesting comments, deathshadow. But could you elucidate on this? …

Shouldn’t they all be H1s then? If they are all H2s, then what’s the H1? The name of the newspaper? Normally a chapter in a book would start with an H1 and then work down, wouldn’t it? I wouldn’t think of the title of the book as the only H1. But maybe I should?

7

That wasn’t the REASON for it, though that was often the effect it provided.

Not the reason why the webmasters wrote that way? No, I didn’t think so either: I figured people who do it do it for SEO reasons or something. The survey didn’t say WHY people preferred the two as h1’s but it seems logical that people feel those two bits of information are equally important and/or want to access them right away using the same tool (h key).

I suppose for a tree it’s not too bad:
h1 site name
|
h1 page title/name
|
h2 whatever - h2 something - h2 something
|
h3 etc

as far as navigation goes I mean. I still don’t put my site name in any kind of header except on the main page (where it IS the name of the page), but I have it in my <title> so unless you turn that off, it gets announced right away before you even start navigating.

Again, the newspaper comparison. Many people would make the largest headline on the front page the H1 and all the other headlines H2’s – which makes ABSOLUTELY NO SENSE as those other headlines are NOT subsections of the large headline, they are subsections of the paper AS IS that largest headline; they’re ALL H2’s structurally even if one of them is presented in larger text.

This would make the h1… what? “Sydney Morning Herald”? Name of the paper?
To many people, each of those articles in the newspaper are completely stand-alone things, meaning they are all headed by H1, not h2. H2 implies the article is a chunk of something bigger…

well a web site that aggregates articles from wherever has no business claiming those articles are somehow part of them. They are displayed on their site (written elsewhere)… is that enough to let them claim <h1>Joe’s News Scraper.com</h1> ?

<h2>Some Guy Rambling on Technorati</h2>
article…

<h2>Grandma Baked Cookies Today</h2>
article…

<h2>Some Dutch Politician Sticks Pen Up His Nose</h2>
article…

I can very much see the argument that those articles are not subs of Joesnewsscraper.com at all… especially when clicking on the little blurb on his main page brings you to a page containing nothing more than the name joesnewsscraper.com and then the article.

Why I’d rather joesnewsscraper.com is some other element, and the article’s title (what that standalone HTML document is actually about) the h1.

When it’s a product page for some company’s product, I’m less sure of that argument. The product description could indeed be headed by an h2 while the manufacturer or selling is the h1.

<h1>Black & Decker</h1> <–is the page about B&D? No, it’s about the backhoe
<h2>Super Ultra Mega Backhoe</h2>
product description…

or

<somethingelse>Black & Decker</somethingelse>
<h1>Super Ultra Mega Backhoe</h1> <–the entire page is about this item
product description…

Some products nobody ever knows the owner anyway:
<small>ConAgra foods owns all your food</small>
<h1>Chef Boyardee Spaghetti with Meatballs</h1>
about product…

I would. The difference is, on the web each web page is considered a stand-alone document. At least that’s what the Googles claim. A book page, however, is always part of a whole book, and does not stand alone.

*edit suddenly I just wondered about short story collections. Hm…

8

Which would make me immediately ask “If they aren’t subsections of the website, what the blue blazes are they doing on the site in the first place?!?”

  1. I’d be interested in hearing where google claims that…

  2. I consider EVERY page on my site to be part of that site, NOT standalone pages… otherwise, why are they on the site? It’s not like I’m giving every page it’s own domain name.

That’s just… silly. idiotic even; I find it hard to believe google would claim that – unless of course it’s being misquoted and/or misinterpreted.

9

So, does a page about an appliance which is on a B&D website call the h1 black & decker? Is the page about Black & Decker? Is it partially about it, mostly about it, anything about it?

The Joe’s example is those sites I see that just randomly gather stuff. I dunno what they are… content mills? Spammy McSpams? In any case is any article on Joe’s actually about Joe’s site? Referencing Joe’s site? Is a standalone article written by the AP that’s published in both Joe’s News Scraper, the BBC and the Podunk Times not have its title as the h1?

I haven’t settled on an answer to these questions, and they keep coming back as the HTML5 people start spreading their “multiple articles each with it’s own h1 on one big page” thing. I have already decided none of my sites will have the site name as the h1 except maybe the first page, since that’s usually about the site itself. But, none of my web sites are news article sites or anything like the Joe examples.

I find it hard to believe google would claim that – unless of course it’s being misquoted and/or misinterpreted.

Likely. What I had been told was, when they search/index sites, they do not search/index sites, but individual pages. This is why a page has a rank and appears on searches as an individual search result. Likely why the SEO freaks are so worried about putting nofollow stuff on their menus that appear on every page… something about fruit juice leaking or something…

10

I would argue this is logical to think this way. If you don’t think each page is a stand-alone document, I have to ask: Do you put some sort of navigation on your site? If you answer yes, then you are saying that page is a stand-alone, or else you would simply link back to your home page and have people navigate solely from there.

11

See, and that’s a matter of perspective – all the pages are getting the same menu and the same heading and the same styling BECAUSE they are part of the same site, NOT because they are separate pages! My answer yes draws the opposite conclusion.

NOT giving them the same menu and header and making people go back to the main page to navigate to me is saying they are separate unrelated pages! Again, the opposite conclusion to the same data.

Besides, sure google scans each page individually; how else is it going to work? I think people are taking how it works and mis-interpreting it into meaning something it doesn’t…

Though as even Google keeps saying, the best SEO is to write for the users following the rules of HTML, not using ‘stupid code tricks’ to try and game the engines. Write for the user, not the engine.

Which when it comes to things like screen readers and other accessibility methods is kind-of the point! WCAG for the win… HTML rules for the win… Graceful degradation thanks to building the site with progressive enhancement for the win… and logical document structure for the win.

Which is why putting a h2 before the h1, skipping to h4’s with no H3’s in-between and multiple h1’s makes little to no sense and can result in broken heading-style navigation on websites.

12

I tend to think of two things which causes this to happen. 1) The are using some sort of WYSIWYG editor that does it automatically. 2) The people making the page sees the size of the heading levels and chooses them on font size. i have seen a number of sites that put footer stuff in an h4 because of that.

13

The more likely of the two – which is automatically presentational markup by people who failed to grasp the simplest of concepts.

Though again, with most people still vomiting up HTML 3.2 and slapping either a 4 tranny or 5 doctype on it, this is hardly surprising.

14

Lol last week I was asked to review this asp site. Each page had two doctypes and the language was set to NL…

15

Each page had two doctypes and the language was set to NL…

Usually I see it the other way around: someone makes a Dutch site, using a CMS made by English-speakers… so the one making the site leaves the default lang to EN and there’s skip link text like “Skip to main content” instead of being changed over to Dutch.

16

Definitely this survey tell us absolutely how we have come over the web since its birth. Most of the concept we were preaching as Usability and accessibility professionals have now come into play. Sensible design has now its own factor on the web.
Good to see the use of H1 specially, which seems like people come to understand why exactly they are making the site, not like just putting a website on the web and tell your friends that see I also have got a website :).

But seriously the statistic that we all want to change is the user of browser. we really want IE6 to die. I am pretty sure that IE6 still has bigger market share for browsers.

17

But seriously the statistic that we all want to change is the user of browser. we really want IE6 to die. I am pretty sure that IE6 still has bigger market share for browsers.

Not all those IE users are IE6 users, BUT if you’re stuck with an older reader made for Windows, it may only work well with IE6.