How to force browsers to scroll pages smoothly to the focused element while navigating with 'tab' key?
Note: I've looked this up but haven't found the solution yet.
As this as marked as accessibility the simple answer is don't.
You may not like that the page jumps about but you have to consider the opposite side effect of changing scrolling behaviour.
What if your user is partially sighted and has the zoom set to 300% on your page. A tabble item such as a link may be many many pixels off screen when zoom levels are so high, having to wait for it to scroll into view will only be frustrating.
Additionally for WCAG 2.1 (applies to level AA I think) guidelines you should avoid animation of any kind or have the option for users to switch it off, you are adding a lot of extra work in needing a setting to remove this scrolling directly within your site. This is because certain cognitive impairments make animations far more jarring and distracting than a simple jump and also that is expected behaviour - changing expected behaviour can also lead to disorientation for people with cognitive impairements.
Another thing to consider is that to achieve this you would have to intercept the tab key - this is a terrible idea as screen readers rely heavily on this key in different scenarios (tabbing in a list of items tabs down to the next item in some screen readers, intercepting the tab key would result in unexpected behaviour.)
Don't worry about it, disabled and able bodied users will thank you for leaving the tab key well alone (as I hate when people slow my scroll speed)
If you did want to do this you would intercept the keypress of the tab key and manually cycle to the next tabbable element - but please don't do it!!
You would also (for accessibility and WCAG 2.1) have to then add an option to remove this functionality within the site accessibility settings (if you have them).
Smooth scrolling is a browser setting (chrome > about:flags, firefox > about:preferences, ie > tools>options>advanced). You might be able to change the browser's setting programmatically, but that would seem like a security risk that browsers would block. It's a personal setting. Some users like it and some don't. If you forced it upon a user that didn't like it, that would not be nice.
Related
I am hoping someone could enlighten me on exactly what is the fix to pseudo classes and content negatively impacting screen readers.
For example, if I have this piece of code in my SASS file:
[bag-total]:before{
content: attr(bag-total);
}
My intent here is for the screen reader to read the value of the attribute or the total amount in the users' cart that he is about to purchase.
The problem right now is the screen reader is not reading the number of items in total inside the shopping cart.
The :before and :after pseudo elements are used in the "accessible name" computation as defined here - https://www.w3.org/TR/accname-1.1/#step2. Specifically, step 2.F.ii
The process looks complex but if you think of simple cases, such as a button, the accessible name is essentially the text label of the button. However, a button that displays "read more" might make sense for a sighted user because they can see the context around the button, but for a visually impaired user that is using screen reading software, "read more" might not be sufficient. It's possible to add more context to the button label using ARIA attributes. The additional context is not visually displayed but is used in the "accessible name" computation, which is why that process looks complex.
The same is true if your button just displays an icon. There is no visible text but you need some way to describe the button's icon so that the "accessible name" will make sense.
If you use :before and :after pseudo elements to add more context to your element, that additional context needs to be included in the "accessible name" computation.
Now, all that being said, I'm not sure what kind of "fix" you're looking for. You didn't really state what the problem is you're trying to fix.
It looks like the CSS and user-agent specifications support what you're trying to do here, but inconsistent browser support may ultimately prevent it from working well.
I tested your method using NVDA on Windows with several browsers, and Internet Explorer was the only one that had difficulty. IE still has a fairly sizeable user-base, so it's probably worth supporting if you can.
Unfortunately, I can't see a good solution to your problem unless you want to use JavaScript or a server-side scripting language. Both of these methods add the content to the DOM, whereby CSS doesn't.
This page has some good information on the accessibility of pseudo-elements that seemed to confirm what I was seeing in my own testing.
https://tink.uk/accessibility-support-for-css-generated-content/
I installed 8.8. And shaking my phone like a maniac but the edit buttons remain in sight. Is that a known issue or should I be doing something different (like adjusting templates or something).
Kind regards
Tycho
If a button is visible or not is configured at various levels. So it can be that your buttons are set to always visible - in which case the shake has no effect.
But if you're just using normal buttons which only appear on float, and they already appear (on desktop and mobile) without float/shake, then it's probably something different.
Best to do some more testing to corner the issue.
I hear of advice of making the .hidden class not as a
.hidden { display: none }
but make it width and height of 1, and using clipping, etc, to make the element as if it still exist on screen but the content is just not visible.
But isn't it true that when we use JavaScript to hide something, the purpose of that element is done, and we want it to not show on the screen and not visible to the screen reader either?
Case 1: For example, if it is an input box, and inside the box there is a grey line of text "Enter keyword". When the user actually clicks on, or keydown, (or using the input event), now we have a JavaScript handler to hide the "Enter keyword" text, because it is just a grey prompt inside the input box. In this case, shouldn't the text be completely hidden, using in fact a display: none, so that even screen reader can't read it? (the user have learned enough to start typing, so the prompt shouldn't really still be there to be read by screen reader, right?)
Case 2: If it is a pop up bubble, for error message, or there is a link "enter your email for our subscription", and it will pop up a bubble, then when the bubble is closed, shouldn't the bubble be really closed totally using display: none? The screen reader shouldn't really still be able to read those content out for a bubble that is done and closed.
Case 3: The only case I can think of is a small fraction that the "hidden" should be available to a screen reader is: it is for a bubble for extra information, such as for the product rating (how many stars out of 5), or extra help info that can pop up when the mouse hover over some "?" icon or link. But even in this case, won't screen readers actually read out "link to more info" or "link to show rating", that is in the alt or title of the tag, and not read the pop up info until the user pops it open?
So my question is: shouldn't there be really two types of hidden. One is display: none type that screen reader shouldn't see (make it the .hidden class), and the other is width: 1px; height; 1px that the screen reader can see (or will read out) (make this the .a11y-hidden class), and whether type 2 might be far less often than type 1?
Mostly, that's it.
EDIT 2014: I switched to the clipping method from TJK at Yahoo! (because of hidden span into a link where only an <i>con is visible).
I prefer position: relative; left: -5000px over clipping 1x1px, I know that Yahoo! team only use the latter but the aim is the same.
Also I'll call it .visually-hidden (from Twenty Sth theme in WordPress and other CMS and frameworks). .a11y-hidden would mean the contrary: it's only visible (perceivable) by screen readers and in plain HTML.
Tabs content, error messages that didn't occur yet (your Case 2) shouldn't be perceived by anybody. A screen reader user will have to click on a tab to show its content as everybody else.
Note: display: none AND visibility: hidden elements will be ignored by screen readers. And also some of them (VoiceOver on OS X in particular) will ignore an element with height: 0, etc
Relevant article : Invisible Content Just for Screen Reader Users from WebAIM
Case 1: the important part being read out is the label associated with for/id to the form field.
If you use a keyboard to navigate from field to field, this text will have disappeared when you'll have focused it and it won't be visible to users that zoom at x00%. HTML5 introduced the placeholder attribute that has the same role as this prompt (this is NOT a replacement for label, this is a hint but few people read one of the HTML5 doc alas) and can still be passed to screen readers even if it's visually hidden.
Case 3: this information should be coded in HTML in an accessible manner and so you wouldn't need to visually hide information out of the viewport or in a pixel.
alt text is the preferred manner (or even better a visual with some real text by its side, while avoiding too much clutter. I've no training in ergonomics and this will often annoy webdesigners that want to remove everything from a page ;) ).
title attribute should only be used on links and you're never certain a screen reader will choose to read them. It's a personal matter and setting on a per site basis. They can be so annoyed by some sites that they'll disable these titles everywhere... Though, it's still one of the best techniques to add information if for some reason you can't do it otherwise.
How do I use this .visually-hidden class?
quick access links (to content, navigation and search input) when they don't appear in the mockup. When focused, they'll be brought to screen as in http://www.nanomatrix.fr/ (press Ctrl-L or Cmd-L, tab half a dozen times on Windows and enable tabbing through links in Safari and/or OS X. See on upper left the 3 links)
on labels when for some (bad) reason, they're not in the mockup I receive. Better have a fix (it's a good one) than doing nothing to improve accessibility when it wasn't thought of beforehand...
on captions of tables, because most of the times showing them is a no from client, external webdesigner, etc
on a span with information next to a font icon when it's coded in a performance manner but not very accessible. There are many ways of using a font icon, I'm only speaking of a few use cases
Theres a lot going on here that needs to be addressed.
Firstly, and ideally, the grey text in the input box should be handled by the 'placeholder' attribute. The browser will give the user a consistent and expected behaviour, and its also easier for you to code!
Secondly, for accessibility ideally all inputs should always have labels. This is so that the input is described correctly to screen readers. You can hide them if the design doesn't call for them (some websites only use placeholder text, but that doesn't mean they shouldn't) be there) - which brings me to my third point - hiding content on screen but not from screen readers:
{display: none} will hide information on the screen AND from screen readers. It's basically a way of making something disappear - for everyone. This is where the .visuallyhidden class (or similar) comes in - its a way of adding context (extra information) to the DOM that will be picked up by screen readers but not read by sighted users and it's a technique used very often to make pages more understandable to AT users without breaking a layout or design of a page.
Its a good idea to use a tried and trusted class, such as the one inside the HTML5 boilerplate, as getting it wrong could penalise you on Google (for trying to blackhat content) or create problems with some screen readers on some devices (e.g. iOS) - position:left and text-indent is not a good solution for a number of reasons, so stick to the 1px and clipping technique.
I'm trying to present my notecards in a web app style.
I'm not worried about caching, or making it work offline.
I just want it render well in the iOS browser.
Here's the link: http://kaninepete.com/flashcard/review.php?Sec=3
I want it to look the same as if you re-size your browser window to 320x480.
The problem is, it always renders a huge amount of blank space off to the side.
I want to lock the scrolling to only the vertical axis (like flipping through notecards),
but also have the text at a readable size.
You can use CSS media queries to set your template on a certain width/height model. This works well and can adjust specifically for iPhone screens.
As for the font size issue you'll probably need to just spend time testing. With that it's going to require some type of virtual simulator or a real iPhone where you can test the site. I just loaded it up onto my iPhone 4 and I see what you mean about additional space - this is just because of your page size. Try messing with CSS media queries I think you'll find the answer in there.
Here is a very handy Google search to hopefully get you started on the right track. CSS3 has a lot of new features. Many of them geared towards mobile :)
Reading your question again, here's some suggestions based on what I think you're looking for.
Make sure your document is valid HTML before you continue. Safari on iOS supports HTML 5, so I'd suggest targeting that, unless your platform targets something different already.
If you just want it to run well in iOS Safari, then code for that. If you want it to look similarly in other browsers, however, then it may be necessary to look at styles targeting the iOS device (via width/height). See http://davidbcalhoun.com/2010/using-mobile-specific-html-css-javascript (It seems hacky, but based on some research a week ago, this still seems to be the suggested route.)
You've got CSS that shouldn't be in there if you want to target multiple browsers. overflow:hidden and set pixel widths.
Generally, I'd say you'll want to tweak your markup as well. List items or headers would be much better than just simple breaks.
Maybe I'm just oversimplifying the question, but it looks to me like all you really need to do is wrap each notecard in a div, perhaps giving each div a <div class="notecard_wrapper">. then just attach a stylesheet that specifies the width and height you want for each card.
This page explains Safari's viewport and how to change it. It will probably fix the font size problem and maybe help with the page size.
Basically, Safari by default simulates a screen that's about 900px wide, when it's actually about 300px (so the page appears zoomed out). This makes pages designed for real computers render properly, but for a web app you usually don't want it to zoom the page at all. The viewport tag should let you control that.
I need help. My main page has a long table that will typically be approximately 2 screens "tall" (assuming a 1024x768 browser window).
I want
the user to be able to browse that table up and down, while always having a set of control buttons available in the currently visible portion of the page.
AND
to retain control over the color scheme of all elements on the page.
The problem is that both solutions I could think of that address the first point (using an overflown div or a frame) involve scrollbars that I cannot style. (At least on Firefox they will invariably be gray.)
I cannot implement a "pager" which breaks the data on the table into chunks which are served one at a time (eg, having a "next 40 results" link at the bottom). The user needs to refer to the full table to find and compare multiple rows throughout the table.
What are my options? My head hurts when I think of moving this entire page to Flash for this reason...
thanks in advance...
i would use jquery and a scrollable div.
Here are some resources to get you started.
http://www.switchonthecode.com/tutorials/using-jquery-slider-to-scroll-a-div
http://flowplayer.org/tools/demos/scrollable/vertical.html
http://logicbox.net/jquery/simplyscroll/vertical.html
Don't change the styling of scrollbars unless you really know what you're doing! However, if you understand the usability implications (and try to make them as user-friendly as possible), try the following options:
If you use jQuery, try jScrollPane.
If you use MooTools, try MooScroll or MooScroller.
The following StackOverflow threads might also be useful:
How do I change the browser's scrollbar colours using CSS?
What's the deal with CSS and scroll bars?
How can one use scroll bar images?