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/
Related
I am building a website and I am attempting to make it as accessible as I can by the use of ARIA tags, role tags etc.
A navigation menu item is "Changing Lives". Where this is being read out by screen readers as "Changing Lives" (as in "Gives" and not "Knives").
Another navigation menu item is "About Us" but it is being read out by screen readers as "About U.S.".
I'm looking for assistance in how to force pronounciations for screen readers.
Don't worry about it, there are many words that screen readers do this on.
The only way you can influence pronunciation (while adhering to best practices) is to set the HTML lang attribute (language) correctly.
With regards to your About Us issue, capitalisation plays a big part in pronunciation. If you have used upper case (either in CSS or in HTML) it may exhibit this behaviour.
Above all do not resort to hacks such as double letters to fix this.....fixing it in one screen reader will break it in 3 others....just follow best practices.
You have the same problem as the user in the following question, and the same answer should apply:
VoiceOver pronunciation issue: "Live" "ADD"
you can ignore it,
you can use different words.
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 looking for a good way to implement reusable buttons in CSS on my forms. The requirements:
- Separate image and text (text is in many languages)
- Rollover effects
- Plays nicely cross browser
- No javascript (if possible)
- Rounded corners
Whats the best way to do this? Years ago I was using the sliding doors technique, but this seems out of date now. Would you use CSS3 with a fallback for older browsers? Any particularly well thought of techniques out there?
Jquery UI buttons are AWESOME. They're fully tested, completely compliant, and really look great. With one line of code, you can have a fully styled button in no time flat. Here's the thing--they can be executed without Jquery (go figure)
First, the tut
So, the standard method is to build an element (a, button, input) with an id and set it as a button in Jquery like this:$('#element').button()
However, if you do it in the manner that the tutorial shows, you just have to add some classes to an element to get a similar effect. So, to make a button out of an a tag, it would just be
Button
In this example, there's no need to set the button with the jQuery button declaration...you're doing it by style only. With the flexibility to style so many different type of elements, it opens up a ton of doors.
You would have to have the Jquery UI css loaded, which offers the added benefit of ThemeRoller, which can style elements on the page with a simple change of a file. It's really a great way to "theme" a site that has to change branding in a hurry, which has made custom themed apps my company puts out extremely profitable.
I would use css sprites for this. You can find out about them here:
http://css-tricks.com/css-sprites/
It is basically a way to make one large image that has all states of buttons(normal, hover, selected). The benefit is it is one http request and you don't see a flicker the first time a hover occurs. If you use this route, the css background property will be the image. You can then use text-align and line-height to center the text that you want to place over the image.
This library, Nifty Corners Cubed uses Javascript but is a fairly clean way to round div tags links, etc. It is tough to find a reusable solution without using a sliding doors derived technique. Otherwise you stuck making none-resuable buttons that have to fit to your size.
You can also take a look at PIE http://css3pie.com/
A sprite is a great option and I do use them from time to time.
Personally I don't mind if my websites aren't identical in all browsers and I go the CSS class route. I keep in mind what is and isn't supported by various browsers and if there is an element that needs to be a certain way I will double check with W3Schools for compatibility.
The main benefit the keeps me using CSS/CSS3 classes is if something changes it is done quickly by text in a single file, if need be I can do a quick change from a 10 year old computer with a dial-up connection (if they still exist) and no imaging software.
Where the advantage of a sprite is they are supported across all browsers and they will look identical (more or less). SpriteMe is a bookmarklet that I have heard of to help with sprites if you decide to go down this path.
I see this as a what do you prefer matter... these questions are what I ask myself when making this type of decision:
How often will it change? Big or small changes? Will it be a complete redesign job if it changes? What do you already know? How much time are you willing to spend learning something that you may not know? What does your gut say for this project?
I hope this can help you.
I'd like to add a description field to an application that can be as long as several lines (or even paragraphs) or as short as a one-liner.
Instead of taking up a lot of screen real estate or have scroll bars, it would be preferable to have the textbox grow based on its input.
On IE6 adding Style="overflow-y:visible" accomplishes this nicely (both on display of read only, and if we are in edit mode).
However, it has no effect on Firefox, or IE7 for that matter.
Is there a relatively easy fix for this?
Thanks!
You can accomplish this using jquery if you want to go down that route. It's a nice effect, kind of like the comment textarea in facebook.
http://javascriptly.com/examples/jquery-grab-bag/autogrow-textarea.html
I have an internal web app with an image at the top of the page, currently containing some english text with drop shadows. I now need to provide localized versions of this page for various languages. My main choices are:
Have a different graphic per supported language, containing the localized text.
Use CSS to position localized text over a plain image, with a complex CSS technique to get drop shadows in most current browsers.
Are there other options? This is for an educational environment, I don't get to control the browser used by the students.
I did try both removing the drop shadows from the graphic, and also moving the text into in a header in the HTML, but neither was appealing. People said it looked like a cheap knockoff of the current page, which wounds my pride.
Personally I'm a big fan of CSS techniques for visual effects like this. The big benefit is that you are offloading the processing of the effect to the client side, saving you bandwith and content creation time (custom text images for each locale is a big order!), and making the page download faster for the user.
The only reason to avoid it is if you absolutely MUST have the drop shadows on very old (IE5) browsers with next to no CSS support.
Edit: Just thought of something - I a few cases like this where I need a specific font or some exact text effect I've used PHP to render the text, with effects, to an image and cache it server side. That way you avoid the content creation process and gain wider browser support in exchange for bandwidth and server CPU time. It's your call if the tradeoff is acceptable.
Generate the images on request server-side for each language, complete with shadows. Cache them as needed.
If you can use Image Magick, you can refer to this tutorial for generating text + shadows...
Maintaining images with text can be a pain - even without localization, I'd avoid it.
Two choices that I would attempt before going with your options are:
Looking for a free program that generates drop-shadow images that you can have your program utilize whenever it detects that new text is available for the title
Using a shadow image that can be repeated as a background image underneath the text
If those don't work, I'd try the CSS, but test it in as many browsers as you can yourself before going live with it.
Well, Safari supports a proprietary CSS property for drop-shadows, but it won't work in other browsers. CSS3 will have drop-shadows, too (actually only one for boxes, but maybe it can be used for text, too, e.g. when the box has a transparent background).
But seeing that most browsers don't even have a 100% CSS2 support so far, I guess you need to go with one of your two options. Of course, there is a not so complex CSS trick to get a drop shadow:
Drop Shadows for Everyone
But they don't look as nice as a real shadow, since they are not blurred. Further you need to have the text twice in the HTML for these to work.