Responsive UI - modify reading order in screen readers? - user-interface

I have a responsive layout that must be accessible for screen readers. The issue is around the order of buttons on desktop vs mobile.
On desktop the button order is
Cancel - Remind Me Later - Learn More
...and the screen reader reads left to right. However on mobile the button order is vertically stacked and is ordered as the reverse of the desktop:
Learn more
Remind me later
Cancel
The problem is the screen reader still reads as if user was in desktop mode - the visual order no longer matches.
Is there a way for the screen reader to change the reading order depending on the viewport?

In general, screen reading software ignores CSS (*). The order of your DOM is the order the screen reader will read it. Even if you used tabindex, that will only control the order of tabbing through the interface. If you use CSS to reposition elements, whether through flexbox or grid or float, the screen reading software will ignore that.
A screen reader user can simply walk the DOM (**) by using the up/down arrow keys. (** The user is not really walking the DOM but rather the accessibility tree, but it's similar to the DOM. Not every element in the DOM will be on the accessibility tree, but it's a similar analogy).
So, the only way to "control" the order that a screen reader hears the elements is by modifying the order of the elements in your DOM.
(*) (If you have a :before or :after pseudo-element with a content property, that property will be read by a screen reader as noted in step 2F of the "Accessible Name and Description Computation")

This is a common issue and there are a few solutions you can do. Without knowing much about your codebase, here are a few suggestions for you:
Not knowing how complex your markup is, you could provide a version of the form elements that are only visible on small screens. That way you can explicitly control the accessibility tree structure.
Another option, you can use CSS (flexbox or grid) to reposition the buttons based your media query for small screens.
While this would work, I would not advice using "tabindex="1", "2", "3" "..." to control tab order seeing as how your UI is not rendering in the correct order anyway.
Hope this helps. Good luck with your project.

Is there a way for the screen reader to change the reading order depending on the viewport?
One solution is to have two sets of the same menu and use your media queries to use one or the other
<div class="desktop">Cancel - Remind Me Later - Learn More</div>
<div class="mobile">
Learn more
Remind me later
Cancel
</div>
CSS:
.mobile {display:none}
#media screen and (max-width: 600px) {
.desktop {display:none}
.mobile {display:block}
}
This way, you will be free to let the DOM order match the visual order.

Related

Way to put more focus on certain div for Mac VoiceOver?

I work for a newspaper and we got a call from someone who uses Mac VoiceOver. He said beginning a few days ago VoiceOver no longer reads the articles on our site correctly. I've tested it with my extremely limited VoiceOver understanding and I can't get it to read the body of the story at all. It might read the lede but it just stops after that.
So is there a way to place a higher VO priority in the HTML? There are so many other elements on the page that are being read before VO even gets to the body of the article.
Here is an example page if it will help anyone figure out why it isn't reading the main body:
http://www.thebrunswicknews.com/news/national_news/professor-historic-outhouses-underappreciated-in-southwest/article_a4319478-fe98-5dd1-9c98-ebabde4ee856.html
It looks like TabIndex is used on this page. This is creating a navigation trap. For example, in the form with the heading "Welcome to the Discussion" there are two input fields with tab index of 100, and 101 respectively. This suggests to me that there are at least 99 other controls with tab index on them. This in itself is an accessibility violation, as the focus order, vs the content order is out of sync, and doesn't make sense. TabIndex (except a tab index of 0) should be used very cautiously, especially when it comes to accessibility!
Now, usually, we would be able to rely on VoiceOver arrow key navigation, to navigate to content elements, rather than active focusable controls, with tabbed navigation. HOWEVER, most of these tab indexed controls are within form elements, and so a different navigation mode takes over, and disables your typical arrow key, VoiceOver navigation. As such, users cannot (without a pretty deep knowledge of how to use VoiceOver/the weird structure of this page) escape from this. As such, what you have is a large keyboard trap, bouncing around approximately 101 different elements on your page. Set all tab index values to 0, or simply remove them, unless they're on elements that aren't usually focusable, and you should be good to go! Or at the very least, the issue that you're talking about will be fixed. There are a lot of other accessibility issues on this page, but fixing this is a good start.

How to emulate mouse position in FireFox?

I'm trying to figure a lot of hover/mouseover related CSS/Javascript on a webpage.
To do so, I use Firefox+firebug inspectors.
The problem, is that whenever I move the mouse out of an element I'm inspecting, all the "hover reactions" are lost.
Is there a way, to fix the mouse position firefox sees so I can freely use the mouse withouth concern about weiter it actually hovers some elements or not?
Well, it is not fixing the mouse position, but when you right-click on an element in the Inspector in the regular Developer Tools, you're offered a :hover menu item (along some other things). Selecting that will put the element into permanent :hover state. That at least should cover the CSS-part of your question. I'm sure Firebug offers something similar.
For the JS-part, I'd just set a breakpoint somewhere.

How to implement a threaded view?

I need to implement a threaded view of sorts in an old VB6 app. It should look similar to this:
So, it's like a TreeView of sorts but there are buttons on the right (for each row) that could be pressed. The view does not need to collapse - it always stays in the expanded mode. The users should be able to respond to each node (via the comment button on the far right). And, of course, users should be able to scroll through the entries.
What are some of the ways I could implement this? I am open to 3rd party controls, paid or not.
VSFlexGrid has an outline mode. You can set the indent per row via the RowOutlineLevel property. It supports word wrap, images, etc within its cells/columns so you should be able to get pretty close to what you want. It also supports owner-drawn which lets you fully customize the cell painting (for example, to get those rounded corners).
I'm sure there are other controls out there as well...

Cool user interface alternatives and improvements for Scroll Bars

Scroll bars are really boring. I've seen a few really inventive new user interfaces for updating these. I believe there are many better ways to spend 10px then with a solid color and static buttons. Here are two examples I've found:
http://www.youtube.com/watch?v=-PnXY4wjuH8
http://chikuyonok.ru/u/demo/infoscroller/
(credit for this link goes to this question uses HTML5 Canvas )
Do you have any other ideas to add to this list? How can we give a better idea of view-status in the document, without wasting so much real estate? How can we add more functionality to the notorious dead space on the right?
Firstly, one should be very careful about “updating” the scrollbar. The scrollbar is a great success story, a simple, elegant, powerful control that is critical for successful computer use and almost universally understood by users. Trying to improve the scrollbar is like trying to improve the ballpoint pen. It’s stayed the same for so long because there’s really not much more you can do. Being "boring" is not a good reason to improve it. Users don’t use an app or site because it has new and "cool" controls. They use an app or site because it lets them accomplish their tasks. To improve the scrollbar, consider how changes can improve task completion.
Good things the humble scrollbar has:
Capacity to scroll one pane-full.
Capacity to scroll one line (fine tuning).
The capacity to do each of the above repeatedly without moving the mouse (so a user reading some content only has to click occasionally after initially placing the mouse over the right spot).
Allows random access to anywhere in the pane by simple linear drag and drop.
Intuitively shows the relative position in the content (e.g., allowing the user to judge how close s/he is to the end).
Intuitively shows the relative size of content by the size of the slider relative to the track.
Supports intuitive keyboard activation via the cursor keys -good shortcuts, and good for accessibility.
Supports clickamatic (pressing down and holding the mouse button to scroll multiple lines or pane-fulls).
Very smooth real-time feedback on user actions.
All in a remarkable compact and unobtrusive control that doesn’t distract from the content (what the user is really interested in).
You don’t want to mess with any of that. In particular, the pop-up scrollbar you link to is probably a bad idea because it interferes with the capacity to scroll by a pane-full by clicking the track. That is perhaps the most common user action so it deserves the greatest number of pixels (i.e., the track).
On the other hand, building on existing scrollbar capability, like the Infoscroller you link to, is a something worth investigating further. For the original research on this concept, see:
McCrickard DS and Catrambone R (1999)
Beyond the scrollbar: An evolution and
evaluation of alternative navigation
techniques. Georgia Institute of
Technology Technical Report
GIT-GVU-97-19.
Obviously, what you show in the scrollbar track depends on your content. A thumbnail of the content won’t work well for a text table or list. For that, Greg Raiz has suggested indicating the values for the current sort order. If there’s not enough space, maybe tooltips or callouts can appear pointing to key places in the track to drag to. MS Word does something similar with this, showing a tooltip indicating the page and section of the current drag-to point.
Here’re some other ways we could build on the scrollbar:
More Buttons. I’ve seen suggestions to include both up and down buttons at the top and bottom so the user can transition between scrolling down and up without having to slew the entire height of the pane. Or you could have buttons to scroll immediately to the beginning and end of the content, handy for users who don’t know about Ctrl-Home and Ctrl-End, saving them from making a long drag of the slider. MS Word includes buttons to execute the last Find or Goto, among other possibilities.
Split bar. On the subject of MS Word, MS Word and Excel scrollbars include a split control to allow you to divide the window into two panes. That would be handy for a lot of other applications, such as browsers and large lists and tables.
Expert activation. If you don’t want to clutter the scrollbar with more buttons and controls, consider providing expert shortcuts via meta keys. Ctrl-clicking an arrow button could scroll the user to the beginning and end of the content. Ctrl-clicking the track could instantly scroll to the corresponding position in the content, particularly useful if you’ve implemented Infoscroller. Ctrl-clicking the slider could pop open a mini dialog or text box to enter a page number, list item identifier, or Find criteria to jump to.
Left side scrollbar. There is some research suggesting we should usually be putting vertical scrollbar on the left side, rather than the right (see Kellener E, Barnes GM, & Lingard R (2001), Effects of scroll bar orientation and item justification, Proceedings of the Human Factors and Ergonomics Society 45th Annual Meeting). Having the scrollbar position consistent with the content alignment means less average slew distances for faster scrollbar use. In the same vein, putting the scrollbar on the left in a browser would shorten the distance between the scrollbar and the Back button for faster navigation. However, the advent of the scrollwheel may have made this idea obsolete.
Great question. Please see RockScroll, which is now standard in Visual Studio 2013 Preview: http://www.hanselman.com/blog/IntroducingRockScroll.aspx
RockScroll in turn inspired MetalScroll:
which in turn inspired RockMargin.
Also, Jetbrains Resharper plug-in for Visual Studio puts a vertical affordance to the right of the scrollbar. The information is displayed as little horizontal bars of different colors. These bars indicate a piece of code that can be improved. Clicking on a bar scrolls the code page to bring the code in question into view:
Also, most file comparison software uses fancy scrollbars. See Scooter Software's Beyond Compare 3.0, which puts an "infoscroller"-like affordance separate from the scrollbar. The affordance on the left is draggable like a scrollbar. In addition, to reduce the need for horizontal scrolling, there is a bottom pane which puts the current line from the left pane on top and the current line from the right pane below. Moving the info-scroller allows the user to scroll both documents simultaneously, which makes "merging" changes between two versions of the same document MUCH easier. Please see:
WinMerge has a different, equally scrollable, left-pane that functions like a scrollbar and duplicates the existing scrollbars. http://winmerge.org/about/screenshots/filecmp.png
Finally, Google Chrome integrates search functionality (the "find bar") into the scroll bar.
And Greg Raiz came up with the ABC Scrollbar:
And Overlay Scrollbars which minimize the non-client area:
And a research, gaze-enhanced scrolling techniques.
I like the Google Wave scrollbar- it seems like they've reconciled scroll bars with Fitt's Law.

Looking for alternatives or improvements to drop down lists/menus on websites

Drop-down lists, menus and combo boxes are all very common user interface elements. Users are accustomed to seeing these elements in native applications and sometimes web apps, but there are a few problems with them.
You have to aim the mouse. Some menus collapse when you mouse out, and some have submenus that you have to aim at to expand.
You can't see the options without aiming the mouse first.
These are the main things that trouble me, maybe other people notice other issues as well. I normally don't use drop-down menus at all if I can help it.
The problem is that I sometimes want to present a long list of options in limited space. Issue 2 is a sacrifice I'm willing to make, but I'm wanting to know if anyone has any tricks to make these drop menus easier to use. Maybe someone has invented a new style of list control.
I'm sure that if these types of controls annoy me, then they annoy users of my site more.
Hmm..one more thing which annoys me about the dropdown list is the inability to control their width as it expands with the text (or is their something which I am unaware of ?).
For an alternate, I think about a little popup which initially displays a list of available options in form of Alphabetic index and when the user clicks on an alphabet link, it displays the relevant options to select from. This will reduce the options to select from.
On the same terms, we can use ajax to build the options on the fly as user types in.
You could try something like Mac OS/X has for its taskbar, similar to the selection bar in YouTube. I think the common term is a bubble bar where small images animate larger as the mouse rolls over them, but shrink back down to such a size that all items are visible when the mouse is not over the control.
#Nrj
width='20px' will keep the collapsed drop down at a width of 20px. Problem is, Inernet Explorer shows the expanded item with this width also, while all other browsers i met so far will show you the full menu.

Resources