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.
Related
Using the exact same CSS,
the onclick pseudo effect works fine with this code on one page of same site:
<a data-url="#" class="btn btn-share referral_button">Button Text</a>
(but admittedly it is on a different page with different divs)
but not on another page, where the code is:
<a data-url="#" class="btn btn-share referral_button" onclick="javascript:$find('ABC').set_activeTabIndex(3);">Button Text</a>
instead of behaving as it should it shrinks when clicked - and sort of reverts to how it would look without any css styled - or at least not the correct css styling
I initially thought it was something to do with the onclick="javascript... stuff somehow clashing/over-riding and affecting the CSS from performing how it should but * EDIT it can't be this because I just removed the whole onclick section and the problem still existed :( **
so it must be something else..
the relevant CSS is here: sorry it's long and probably bloated. the most relevant stuff i believe is at the bottom...
https://docs.google.com/document/d/1N7YQ5YuvY6DJn8-nr4sinx4LY7WOS88eErpRHe4IE_g/pub
Seeing as how its an invalid syntax, I would say remove the " \9" from all of your :active and .active statements
Like below:
.btn.active{background-color:#cccccc \9;}
EDIT: Furthermore, (not really relevant to the answer)
Your CSS is a pretty hot mess. (No offence)
You can easily clean that up and make it a lot more manageable.
Plus, it could just be my tired eyes, but it seams like half of it is just repeating and/or overwriting the other half (which goes back to cleaning it up and making it manageable).
Honestly though, your the one working on it, so its as long as you can read it and use it. To each their own. I prefer my CSS quite readable in a dev environment.
The most obvious suggestion is there is something on this mysterious "Other" page, that is overriding the style.
Use a tool like Firebug for Firefox to inspect the elements and its' styles this may give you a hint as to what is overiding the behaviour you are expecting.
Also check that the CSS is the same on both pages if you are not using a common CSS file.
Read up on CSS Specificity, which is could be the root cause of you problem. This could help explain why style b is overiding style a.
It boils down to some difference on the two pages.
When using IE8 to view IE7 through the developer tool's browser mode feature, I am having an odd recurring problem with CSS. When I make changes to an external stylesheet and then reference that class in the HTML, it's like IE7 won't recognize it at all. If, however, I put that same styling inline, IE7 will obey it. Has anyone heard of this before? Here's a simple example to help illustrate what I'm saying:
External stylesheet:
.bold {
font-weight:bold;
}
Call in HTML:
<p class="bold">My paragraph here</p>
No changes will be effective in IE7, although all other browsers are fine.
If however, I do this:
<p style="font-weight:bold;">My paragraph here</p>
IE7 seems happy. What's the difference? Do I really have to make CSS changes this way, or is there another workaround?
I'm baffled as to what the issue could be. I don't know if the developer tool's browser mode has a quirk and doesn't quite work as a real-life version of IE7 would, or if this is something completely different. I am using IE8 (I can't upgrade to IE9 at this government computer), but I've heard the problem persists with my changes in IE9's browser mode of IE7 too.
We're using ColdFusion to generate the HTML, using an HTML5 doctype (), and I've added a timestamp parameter to the 2 external stylesheet references so the browser is forced to grab a new copy every time.
Any help with this mystery would be hugely appreciated - thank you!
======
For #Stano or anyone else who is interested in recreating the exact problem, here is a stripped down version of it: https://docs.google.com/open?id=0B02DZPpIlMwGSk1VZHRDUHNCTkU (Can click File > Download to get the zip). Notice in IE7, "Photographer" is fine because it has inline styling, but the others aren't picking up anything.
With regards to your comments, you're right in saying that it could be a caching issue, but it could also be an issue with that stylesheet (though it doesn't look like that's the case), another stylesheet, or invalid HTML.
One of the things that I want to correct you on, because I think it may influence your understanding of how CSS and HTML interact, is that class attributes in HTML elements do not call CSS. Rather, CSS rules tell the browser agent how to render things with certain attributes. This is why we are able to use the elements ID, name, groupname, class, and other values to identify which elements to apply which class to.
I mention this because if you have invalid HTML (a missing end tag, a missing arrow, etc.) it can do all sorts of weird things. A few days ago it helped me solve an issue where a misplaced tag was actually causing a script of mine to loop on one of my pages.
Take a quick second and validate your HTML using the W3C Markup Validator.
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
Is <H#> element inside HTML <li> element considered semantically correct?
Yep. According to http://validator.w3.org/check anyway... it's a great tool.
There are many tools that no web developer should be without. One of those tools is a good HTML Validator add-on for your browser.
Firefox HTML Validator Add-on:
http://users.skynet.be/mgueury/mozilla/
Chrome HTML Validator add-on:
http://robertnyman.com/2010/04/07/html-validator-extension-for-google-chrome/
I especially like the one for Firefox. If there is a validation error in your HTML, not only will it tell you, but it also tells you why it's bad and how to fix it.
To answer your question, I do believe h# are considered valid inside an <li> element. But it may also depend on DOCTYPE as there are different rules for different HTML DOCTYPES. However, with the validator you'll never need to ask a question like this again :)
I have a JQuery (using JQuery 1.4.2) problem that exhibits only in IE8 in standards mode, on one specific DOM element but not on other nearly identical dom ellements. The best example of why it makes no sense is below:
$('span.error:visible')[0].style.display
The above piece of code returns "none" which unless i am having some sort of brain aneurism is impossible without there being a bug in either JQuery or IE8. This only occurs in IE8 in standards mode, not in any other browser or on IE8 compatiblity mode. The span that it finds is actually an ASP.net validation control so i only have a limited amount if control over what it renders to the browser. When i inspect the DOM using IE8 developer toolbar and copy the HTML from the DOM it gives me the below:
<SPAN style="DISPLAY: none; COLOR: red"
id=ctl00_cphContentBody_mnMainMiddleNames_ebvMiddleName1 class=error
controltovalidate="ctl00_cphContentBody_mnMainMiddleNames_txtMiddleName0"
errormessage="JQuery should not find this" display="Dynamic" validationGroup="MiddleNames"
isvalid="true" validationexpression="[A-Za-z][A-Za-z '\-]*[A-Za-z]*">JQuery should not
find this</SPAN>
If i just do a view source and copy and paste it i get the below:
<span id="ctl00_cphContentBody_mnMainMiddleNames_ebvMiddleName1" class="error"
style="color:Red;display:none;">JQuery should not find this</span>
If i create a simple HTML file containing just either of the above pices of HTML then $('span.error:visible') does not find the spans and i am unable to post code to be able to reproduce this problem. But in the actual asp.net page if i run $('span.error:visible')[0].style.display it returns "none" and if i run $('span.error:visible').text() it returns "JQuery should not
find this".
tl;dr How can $('span.error:visible')[0].style.display return "none".
Edit to answer Nicks comment.
$('span.error:visible')[0].offsetWidth returns 3
$('span.error:visible')[0].offsetHeight returns 22
Which is puzzling, i found the below on the Jquery site.
In jQuery 1.3.2 an element is visible
if its browser-reported offsetWidth or
offsetHeight is greater than 0.
THe element isn't visible, but acording to the above JQuery thinks it is.
What does this change mean? It means
that if your element's CSS display is
"none", or any of its parent/ancestor
element's display is "none", or if the
element's width is 0 and the element's
height is 0 then an element will be
reported as hidden.
So is the above just wrong. Display is "none" but offsetWidth and offsetHeight are not zero.
This appears to be a browser bug, though whether jQuery should handle it is certainly up fo debate. The :visible selector is really just a reverse :hidden selector and it's checking if the element has a 0 for offsetHeight and offsetWidth (e.g. hidden being defined as "using no space in the page".
IE shouldn't allow display: none to have an offsetWidth and offsetHeight, so the root of the problem is there. Should jquery add handling for this? perhaps so, there's already a bug filed which may be exactly your issuehere.
I wonder if this is something to do with visible vs hidden:
visibility: hidden hides the element, but it still takes up space in the layout.
display: none removes the element completely from the document. It does not take up any space, even though the HTML for it is still in the source code.
(from http://webdesign.about.com/od/css/f/blfaqhidden.htm)
Wwhat do the following give you?:
$('span.error:not(:hidden')[0].style.display
And
$('span.error:visible')[0].style.visibility
You could also look at the CSS in more detail by using the IE8 Developer Tools (F12).