I'm trying to get an aria-live region to work correctly with JAWS 11 and IE8.
Using the code below, I can get JAWS to announce the new value when the button is clicked, but the behaviour is not what I would expect.
JSFiddle of this example
<!DOCTYPE html>
<html>
<head></head>
<body>
<button onclick="document.getElementById('statusbar').innerHTML = parseInt(document.getElementById('statusbar').innerHTML) + 1">Update</button>
<div id="statusbar" aria-live="polite">0</div>
</body>
</html>
Using my JAWS11/IE8 configuration, on each click of the button I hear:
Click number HTML Value (after click) JAWS says
------------ ------------------------- ---------
1 1 "Update button 0"
2 2 "1"
3 3 "2"
The problem, and my question is: how do I make JAWS announce current value of the aria-live region, rather than the previous value of the aria-live region?
I'd also be interested in how other screen readers will handle this functionality.
Your code is correct. Apparently, the "1 behind" has been discovered. From the link, it looks as if using aria-atomic="true" may fix the problem. However, the example as given does work properly in IE9 and Firefox.
If you haven't stumbled across them already, check out the test-cases on codetalks and accessibleculture.org. There are a lot of subtle differences to be aware of. Just don't be surprised when the tests fail! Over the past year or so, I've come across a few (inadequate) tricks which may help you.
Method 1: role="alert"
The alert role is supposed to be equivalent to aria-live="assertive", but older versions of JAWS didn't handle it properly. Check out these examples from February 2011, which states that:
If you are looking to support JAWS 10 in IE7 or IE8 at all, it is likely best to double up on alerts with both role="alert" and aria-live="assertive". While this is somewhat redundant since, by definition, the alert role is to be processed as an assertive live region, doing so does allow JAWS 10 to automatically announce the updated alert's contents in those two browsers.
Both Firefox4+ and IE9 do not require this. But it would be something like this:
<div id="statusbar" role="alert" aria-live="assertive">
Contents will be spoken when changed
</div>
Method 2: focus forcing hack
By dynamically creating a DOM element and forcing focus to it, you can "trick" most screen readers into reading the contents. It's hackish, but effective...and somewhat the point of the Create and Focus example. Simplified, you can do something like this:
<div id="statusbar" role="alert"></div>
$('#statusbar')
.clear()
.append('<div tabindex="-1">' + newString + '</div>')
.children().first().focus()
;
Merely hiding/showing the contents instead actually works fairly well most of the time. However, VoiceOver's focus lingers on the element and does not speak its contents when shown again. Thus, removing it from the DOM seems to be the most foolproof method for now. I don't like it, but such is the state of things.
If you are using JAWS, i think you need also to configure the default mode; because the screen reader have a "read only" mode. this problem can be solved via press:
(Insert + z) to turn on/off the read-only screen readers.
http://www.mozilla.org/access/qa/win-webcontent-jaws.html
Related
I am relatively new to working with JAWS and trying to fine tune some discrepancies between Firefox and IE when working with it.
Currently, I have a crystal reports popup window that has two toggles, for example, one is for find. That once it's triggered, the user can type their search string. This div has an aria-role="button"as well as an aria-pressed="true/false" value. However, in IE11, JAWS is not reading back whether the button is pressed or not like Firefox does.
Any insight? Has anybody else hit this issue?
<div tabindex="0"
title="Find"
class="someClassName"
id="someID"
role="button" aria-pressed="false">...img...</div>
Note: I've replaced the lengthy classes and auto-generated ID.
It might be a JAWS bug. However, basically it is not good to do things like <div role="button">:
Do not do this:
<h1 role=button>heading button</h1>
Do this:
<h1><button>heading button</button></h1>
© Www Consortium, The second rule of ARIA use from here.
So, in your case I'd use a <button> rather than a <div>.
Actually, the first rule of ARIA use also applies and maybe is even more appropriate here:
If you can use a native HTML element [HTML 5.1] or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property
to make it accessible, then do so.
On those Windows machines with Skype installed, it tends to convert all phone-formatted numbers to Skype links so you can click it in order to make a call on Skype.
The question is how do you prevent that to happen for a certain number on page?
Try not outputting the numbers as a single piece of text. Instead of
<span>888-555-1212</span>
try
<span>888-</span><span>555-1212</span>
and it will disable skype
Update
This answer is no longer accurate - see Daniel Byrne's answer for more information.
Using CSS only, it can be removed by overriding the styles used by Skype. Try adding these two lines to your stylesheet:
span.skype_pnh_container {display:none !important;}
span.skype_pnh_print_container {display:inline !important;}
Skype has taken to adding a randomly generated string of numbers to the end of their span tag, so the above response from Groo is not entirely accurate anymore. To correctly select all Skype tags on a page, use CSS3 wildcard selectors like such :
span[class^='skype_pnh_container'] {display:none !important;}
span[class^='skype_pnh_print_container'] {display:inline !important;}
the ^= operator causes an attribute selector to mach elements that have an class containing a value that STARTS WITH 'skype_pnh_container' and 'skype_pnh_print_container'
<meta name="SKYPE_TOOLBAR" content="SKYPE_TOOLBAR_PARSER_COMPATIBLE" />
The official solution is to add the following meta tag to the head section of your webpage. This will prevent skype from doing any reformatting on phone numbers.
<meta name="SKYPE_TOOLBAR" content="SKYPE_TOOLBAR_PARSER_COMPATIBLE" />
This is a vendor-specific tag. See Skype Toolbar meta tag
EDIT: Sorry, I just discovered that IE9 has issues with this solution as it does not support soft hyphens.
There is an alternative solution to this problem:
You can use a soft-hyphen character () inside the phone number to address the issue. For example, given the number
<span>0664 111 222 3</span>
change to
<span>0664 111 222 3</span>
and be happy :)
I just found that if you use the new HTML5 tel protocol it blocks the Skype junk from appearing:
1 800 123 4567
I saw over the interweb a lot of possible solutions javascript solutions, meta tags, css and maybe I found an hack actually working for my websites, I tested on some computers and it work and I think it will work until skype don't change something in their code.
I was looking what is the skype exactly doing on our pages, and it creates some span around the phone numbers, as you already said, but it even add an tag at the end of the document, just after the body closed tag.
And here I saw the trick! Just before that object there is a configuration tag:
<span id="skype_highlighting_settings" display="none" autoextractnumbers="1"></span>
This is added dynamically by the plugin! but here the solution become obvious, to finalle stop skype messing with your design and avoid changing phone number the solution is to insert very early in the document the following tag:
<span id="skype_highlighting_settings" display="none" autoextractnumbers="0"></span>
notice the autoextractnumbers="0", here is the trick. The document will not validate anyway with that tag because there is no attribute "autoextractnumbers" but i noticed that it works even if commented:
<!-- <span id="skype_highlighting_settings" display="none" autoextractnumbers="0"></span> -->
And that's it! Enjoy your webpages free from messy plugins! And your web page will still validate correctly. Hope it works for you too! I have tested on a couple of computer 3 different browsers and 2 different skype versions, for now it works for me, let me know if it works for you too and if it works share it :)
I added a space in the first term of the number.
Instead of (888) 222-3333 I entered ( 888 ) 222-3333
Granted: may look weird, but it works and it is simple.
I added a hyphen in a span before the number and then set display:none on the span style, which worked.
<span class="anti-skype-hyphen">-<span>01273 200 ***
All you need to do is insure your CSS selector is more specific than the selector Skype uses. In the current skype style sheet they use:
span.skype_pnh_container span.skype_pnh_highlighting_inactive_common span.skype_pnh_text_span {...}
You will need to add an extra class — your own website context — to this selector, i.e.
.myclass span.skype_pnh_container span.skype_pnh_highlighting_inactive_common span.skype_pnh_text_span {...}
Try this. It substitutes spaces in the phone number with an invisible span + the original space char. So skype cannot understand it is a number and our beloved phone number stays the same :) I had to use this approach since I usually let the content administrator change phone numbers at his will therefore I could not use a hard coded number inside javascript. Of course your markup should look like <span class="phone_number">your number with some spaces inside it<span>.
$(document).ready(function() {
if ($(".phone_number").length>0) {
$(".phone_number").each(function() {
$(this).html($(this).html().replace(/\s/g,"<span style=\"display:none\">_</span> "));
});
}
});
You can also leave the number alone and remove it with JS.
jQuery(document).ready(function(){jQuery('.skype_pnh_container').parent().html('(555) 222 - 3333');
jQuery('.skype_pnh_container').remove()}
It is harder to do in normal HTML, but Skype doesn't remove the parent container, so put the number in something with an ID, you can do a "getElementById" on it, set the innerHTML to the phone number.
document.getElementById('phoneNumberContainer').innerHTML='(555) 222 - 4444';
If you are using PhoneGap on iOS this can be a UIWebView issue (separate from Skype).
The following line fixes the problem if you don't want automatic links generated in UIWebView:
self.viewController.webView.dataDetectorTypes = UIDataDetectorTypeNone;
inside AppDelegate.m in -(BOOL)application:(UIApplication*)application didFinishLaunchingWithOptions:(NSDictionary*)launchOptions
So I have a form and I'll have error messages associated with each input/element.
I've come up with this use for the <aside> tag and was wondering what people thought:
<section class="fieldrow" id="rowJobTitle">
<label for="txtJobTitle" id="lblJobTitle">
<span>Job title:</span>
</label>
<input type="text" id="txtJobTitle" name="txtJobTitle">
<aside id="errJobTitle" class="errormessage">
<span role="alert">Please tell us your job title.</span>
</aside>
</section>
Then I'll be using CSS to show or hide the <aside> errors with a little JS to change this.
I know I could just use the span, and be done with it, but a span tag has no semantic value, and all the (short and vague) info I've read on <aside> seems to say there's no problem with this, but I was hoping that I could either get some confirmation, or someone who's tried this before and found a good reason not to.
Thanks, Si.
The <aside> tag is supported in all major browsers.
There are, however, potentially more elegant ways to do this, and <aside> is not particularly semantic for what you mean. From the HTML5 specs:
The aside element represents a section of a page that consists of
content that is tangentially related to the content around the aside
element, and which could be considered separate from that content.
Such sections are often represented as sidebars in printed typography.
Your error is not really separate from the content, so it's a fairly inappropriate choice.
You should look at how Twitter Bootstrap does in-line form errors.
All that said, this is semantics, and therefore inherently subjective. If it makes sense to you and it works, why not use it?
EDIT
Upon reading Rob's link, <aside> looks even more inappropriate than I thought. Since <aside> is not a sub-element of the <input>, there is no reason a parser would think it related to that <input>. I would avoid its usage in this context.
MDN gives some use cases for this, and yours doesn't fit:
they often contains side explanation like a glossary definition, more
loosely related stuff like advertisements, the biography of the
author, or in web-applications, profile information or related blog
links.
The <aside> element is not supported by IE 8 and older. This means that any styles you set on it are lost in those browsers. You can partially work around this by using JavaScript code that “teaches” the element to them, but is this all worth the gain? What exactly is the expected gain?
Logically, the use described does not match the HTML5 semantics. The descriptions there are vague, but I don’t think an error message can be characterized as tangential when it is displayed and relevant; it’s really the key content then. It is not separate from the rest of the content; instead, it expresses vital information about it.
An advertisement would be a candidate for <aside>, and so would an anecdote, or a history note, or generally content that is not necessarily by any means but has some connection with the main content.
I have not seen any evidence of any software such as search engines or browsers or browser add-ons actually making use of <aside> markup. Just speculation about what might be done.
I think there’s a fundamental flaw in the overall design, making the question about element semantics even more theoretical. What happens when CSS or JavaScript is disabled? Right, the user always sees the error message, even when he has not entered input at all or the input is all correct.
A better approach, assuming that this is about errors detected in client-side code, is to keep the error message texts just in JavaScript strings. When an error has been detected, a new element is added, or existing element content is modified, to make an error message available; and it would then be wiped out when the error has been corrected. (No need to rely on CSS here.)
This way, the error message could be placed before the field, on the right of it, or below it. It would not matter much which elements you use for it (search engines won’t see it, and browsers are hardly expected to do anything special with it on their own), but <div><strong>...</strong></div> would probably a good choice.
Since it's related to the article, and therefore the context (most important), this should be acceptable. I even think it's a very good use of aside. See this.
EDIT: With all the discussion, I'm thinking there is no appropriate, semantic element to do this and the best one to use would be a generic div element. We're trying too hard to force a HTML5 element.
I know its my fault. I know by the way the height is working correctly with the packages and that I offset the problem (just to get a design done) by using a bunch of breaks (br tags) lol.
Anyways, the site looks exactly how I want it to in chrome (minus the breaks (br tags) hack)...In firefox, its a mess. It actually looks good on IE...but not functional -.-
Will take me a good 2-3 hours of tweaking and changing tid bits of the CSS. Would take a CSS expert 5 minutes, so I came to ask what the heck is going on? Is chrome just really forgiving of my bad coding or is firefox confused?
My main concern right now is getting everything to look the same, and properly (none of those breaks (br tags) hacks). Then I will focus on getting IE functional later.
Here is the site.
To fix the Payment Section in firefox i have modified your html as follows-
<div class="Savings0 custom-radio-Length"><label style="border:white;"> </label></div>
<div class="Savings3 custom-radio-Length"><label style="border:white;">15% off Total <br/> Save $1.35</label></div>
<div class="Savings6 custom-radio-Length"><label style="border:white;">20% off Total <br/> Save $3.60</label></div>
<div class="Savings12 custom-radio-Length"><label style="border:white;">25% off Total <br/> Save $9.00</label></div>
After going through the validation as Sotiris suggested, I realized that having block elements in an inline element was causing firefox trouble.
I had DIV's and H3's in label tags, which is why it got messed up. Weird that IE8, Chrome, Safari still displayed OK...But firefox got weird. I understand its valid for firefox to get weird because it was against the rules to do so, but it should be more forgiving about that.
I replaced using H3 with a span that had similar formatting that I wanted, and also replaced the DIVs I had as containers to inject HTML using javascript and instead just appended the HTML instead of looking for a DIV.
I'm trying to change cursor mouse on my website with custom images.
Here is my actual CSS:
<style type="text/css">
<!--
body {
cursor:url(images/default.cur),auto;
}
a:hover {
cursor: url(images/hover.cur),auto;
}
a:active {
cursor: url(images/wait.ani),auto;
}
-->
</style>
Firefox 3.5.6 does change the default cursor with my .cur file but the problem is that .ani cursor doesn't work with Firefox (and even .gif). It does work on IE.
The cursor files I'm using can be found here.
The other problem is that I'm just changing a:active image to animate my cursor but it disappear fast.
I would like to change cursor when we click to go to some page and the cursor to become "normal" once this page is loaded.
What I'm looking to is a way to change cursor when somebody clicks on some internal links of my website.
I wouldn't have to change all my links to do this, but it doesn't seem to work.
I thought about some window.onload JavaScript but I didn't achieve to write it and there might be better ways.
Thanks for your CSS or JavaScript suggestions.
Please don't give design feedback when asked for programming solutions. It is not the role of developers to pass back design critique. It may not be his decision, it may not work but he wants to try it and we should help. If you've been in an environment where programmers pass critical judgement on every design decision you'll realize its very destructive for the whole team. Designers and team members will value you a lot higher if you refrain from commenting on whether or not you agree with what they want to do unless asked. I hope if you think about it you will understand why its important.
Don't. How would you like it if you went to your friend's myspace page and your cursor suddenly turned into a big purple dragon and you had no idea where it was actually pointing.
It's jarring to the user, therefore irritation. If you want to let them know something is working in the background use an animated gif displayed over the page, not as the cursor.
If you have too, you may be able to set it with javascript on all your the elements on the page. I don't think it cascades. If it does, just set it on body and be done with it.
if using ASP, it simplifies things a bit to use resolve url... ie
cursor:url('\<\%\=ResolveUrl("~/img/magnify.cur")\%\>');
Evidently I'm inclined to agree with the other statements, as familiarity is key in any good design, customizing an environment to such a degree that the user feels either unfamiliar with it or under the impression that somehow their system is altered,is a bad bad bad design and reflects poorly on the designer as well. I'm not saying be dull in design, but be a tad reserved.
I might not like MetroUI (rather Metro Web Design) much, but I love it's root,the design concept of "Bauhaus".
"There is beauty in simplicity."