Last modified: 2013-09-23 20:42:46 UTC
See https://en.wikipedia.org/wiki/Wikipedia_talk:Notifications#Accessibility_concern
Why would the number be at the bottom of the screen? The number appears immediately after your name in the HTML whether the browser has JavaScript turned on or off.
(In reply to comment #1) > Why would the number be at the bottom of the screen? Because the links to the user's user page, talk page, contribs etc (<username>/Notification/Talk/Sandbox) are way below the page content in the HTML. They're in the hidden "Personal tools" heading.
I have already mentioned this issue on Id8dd1454. The notifications aren't a part of the personal menu and shouldn't be included in it.
The Fangs screen reader emulator is a good way to figure out how a page reads with a screen reader: http://www.standards-schmandards.com/projects/fangs/
Perhaps role=alert is an idea ? http://blog.paciellogroup.com/2012/06/html5-accessibility-chops-aria-rolealert-browser-support/
>I have already mentioned this issue on Id8dd1454. The notifications aren't a part of the personal menu and shouldn't be included in it. I strongly disagree. The notifications are a part of the personal menu. They are only related to your particular user account. They are not related to the site in general or the article you are viewing. The problem here is that the personal menu is at the end of the HTML which doesn't make any sense to me. The personal toolbar should be moved to the top of the HTML.
(In reply to comment #6) > The problem here is that the > personal menu is at the end of the HTML which doesn't make any sense to me. > The > personal toolbar should be moved to the top of the HTML. The menu is at the end of the HTML, as this is the widely accepted practice in web design since when we stopped using tables for layout. This is to make the actual content load and appear first, which is useful for both users on slow connections and people using screen readers, text browsers and related software. The notification area, however, might be more important than the content, and thus it might be placed before it. This is how the orange bar is placed.
I'm not sure role=alert makes sense for this as that seems to be specifically for alert messages. How do other sites with notifications handle this? @Bartosz Dziewoński: You make a good case. Perhaps we should have an alert that is separate from the badge in the user menu.
FWIW, I have not been able to find a single other major website that loads the menubar after the content. Flickr, Facebook, Apple, Yahoo, Ebay, etc. all load the menubar first. I would like to hear from Graham about what is preferred for people with screen readers. Do people with screen readers prefer to get the user menubar before the content or do they prefer to get the page content first?
As a screen reader user, I'd prefer the actual personal menu to be closer to the end of the page as the links there (except for the notifications feature) aren't really that important compared to the content of the articles. Perhaps an additional alert on the top of the page would be a good idea. The problem I find with role=alert is that it's easy to miss (screen reader users tend to cut off their speech all the time to speed things up) and there's no way to review the alert once it's been spoken.
@Graham: You said: "screen reader users tend to cut off their speech all the time to speed things up." I was struggling to figure out how this mattered, but I think I now understand. You are basically 'programmed' to skip/break off certain things automatically when you are reading a page right ? So in the old DOM location, this was less of a problem to you, because the notification was basically part of the content 'proper' of a page, just before the header level 1. This is a location where you usually don't skip/break off the notifications right ? I'm struggling to find a good solution to this. Perhaps in addition to setting role=alert, we could use aria-flowto. We could set this conditionally on wether or not there are new message. If there are new messages, a 'flowto' on Header level 1 for instance, could direct the screenreader to the new messages indicator. Then we put an aria-flowto with a list on the indicator, which would give the reader the option to continue reading the personal tools list, or to go back to the content.
Yes, and JAWS sometimes just cuts off alerts anyway on its own volition, which is really annoying. Your suggested solution is worth a try. Or we could move the personal tools up and provide a new heading for the actual content ...
There's one youtube video clip here, that gives a brief insight into the speed at which screenreader users tend to listen. https://www.youtube.com/watch?v=izrC4R7SsH4#t=1561s Earlier on in that video, he's set it to read a lot slower, and usually lets the software read most of the lines for our benefit, but he occasionally cuts off words, often truncating full urls, eg. http://youtu.be/izrC4R7SsH4?t=16m58s There are 2 other useful videos, linked at https://en.wikipedia.org/wiki/Wikipedia_talk:Manual_of_Style/Accessibility#Good_videos_demonstrating_screenreaders_in_use (both a lot shorter), and I'm hoping to find more. As Graham notes above, the firefox addon, Fangs, is quite useful for understanding the way a screenreader works. Here are 2 screenshots; the second shows how far down the page the "0" notifications indicator is. http://i.imgur.com/Ta5DDT5.png and http://i.imgur.com/pfSC4BK.png Or use NVDA (windows) or Orca (*nix) [both free] to try a screenreader directly. I think Derk-Jan's suggested solution could work well.
Prioritization and scheduling of this bug is tracked on Mingle card https://mingle.corp.wikimedia.org/projects/flow/cards/210
