I have multiple sets of dynamic content on my page that get updated following some user interaction. I want the updated content to be read out by a screen reader but the live region is not being read by NVDA on chrome. It's working on Firefox though. Please help. Jaws and chromevox on chrome are also not working.
Edit: December 2020 This answer is not so accurate anymore. Chrome has made some great strides in improving accessibility and this answer is likely not relevant if you are still experiencing this problem. I would suggest looking into some of the aria-live specs to better understand how it should be used, as most issues with it not being announced are likely due to things that can be fixed in the implementation rather than an NVDA+Chrome issue.
Original Answer:
Chrome is not commonly used by screenreaders and is lacking in some key accessibility areas. NVDA is most commonly used with Firefox as it's the one of the best browser-screenreader pairings.
This resource from a leading accessibility firm doesn't list chrome as supporting it (although Chrome is significantly far behind in terms of adoption by users with assistive technology - they aren't even mentioned on the page): https://www.paciellogroup.com/blog/2014/03/screen-reader-support-aria-live-regions/
If you're interested in common browser pairings (eg. which screenreader/browser combinations are worth supporting to accommodate the majority of users), please keep an eye on the webaim screenreader surveys - they're the best resource I've come across for statistics.
http://webaim.org/projects/screenreadersurvey6/
apologies for not being able to directly answer why Chrome doesn't seem to work well with NVDA - It's a dangerous road to go down as there are numerous areas where they don't work well together. Considering the usage of Chrome/NVDA users it might not be worth it.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
Which syntax and features should I use if I wanted to write a webpage that could be correctly parsed by any device realistically still in use?
By currently in use I mean also devices whose usage is not statistically meaningful to be included on browser usage statistics, but still reasonable enough to be used in the real world without being too much of a stretch: e.g. A screen reader, a Point-Of-Sale/Kiosk Device, an Internet appliance like a smart TV or a console.
I've recently been assigned to develop an HTML landing page requiring support for - hear me out - the ancient Microsoft Internet Explorer 6. Yes, you read that right.
Long story short, it was in the requirements for a public administration project that was in a legal limbo for a long time, and reworking these requirements would be more problematic than developing it and be done with it. At least according to my boss. Besides, it shouldn't be that much different than writing a current-day HTML newsletter.
But it got me thinking - what's the oldest browser (as in, the one with the oldest HTML standard support available) that I could realistically find in the wild?
I'm not talking about relevance or caniuse-level-of-support numbers, just something that for some more-or-less realistic reasons (excluding "here's a Windows 3.1 VM getting to the internet" retro challenges) people would still be using to get online. Also some security requirements (mostly updated SSL/TLS) cut off quite a bit of older devices, mostly games consoles like the Dreamcast, PS2 w/Network Access Disk and the PSP, or the original Nintendo DS, so those are also excluded.
Other than the aforementioned IE6.0, I can think of Opera Mini browser (which version?) for some legacy mobile phones, or maybe some kind of internet appliance still using the Netfront runtime (IIRC The Playstation 3 still uses a pre-webkit version of it).
Any suggestion?
preword - apologies this became a bit of a rant, I will try and tidy it up later and focus it more. I also understand you may have to listen to your boss so this has become me ranting on your behalf to your boss. I hope you can use some of it to construct a strong argument with your boss to get the spec changed. It also doesn't answer the question as it is titled. Probably worth a few down votes but I enjoyed having a rant!
Given the comment the OP asked this answer is applicable to that.
What are the oldest browser standards I need to support for accessibility?
The WebAIM annual survey is a great place to get this information.
Under the section 'Browsers' we can see that 2.1% of respondents still use IE 6,7 or 8.
Unfortunately they do not indicate what split of those who use IE6 but I would imagine it would be less than 0.1% overall as very few sites still operate on IE6 correctly.
I personally develop to IE9 standards, so use ES5 for JavaScript (or compile to ES5), HTML 5.0 features and CSS3 non-experimental features.
The reason for this is that those who do use IE8 and below tend to be screen reader users due to compatibility with the software they own. They also tend to use a very specific set of websites due to the fact that most websites just will not work for them.
Many people would argue that you must include everyone, and in an ideal world you should. However you also have to consider that your goal in accessibility is to provide the best experience possible for the widest number of people. This is not possible using IE8 and below as you lose a lot of the HTML5 standards that are useful for accessibility (particular form related attributes, navigating by regions such as <main>, <nav> etc.).
So what about the people stuck on IE6-8 then?
As stated they tend to be screen reader users. The beauty of this is that as long as you develop valid HTML, user correct WAI-ARIA attributes etc. (basically go for AAA WCAG 2.1 rating or as close as possible, at least AA rating) then in IE6-8 the site will still function reasonably well and be usable, even if not perfect.
CSS is where your main struggle will be, making a site work in IE6 is just horrible if you still want to follow best practices (try styling a button for example to make the font size large enough and colour contrast AAA rated). Also how do you then make it responsive for mobile users without hundreds of hacks?
So what if you have to support older browsers.
You can provide a separate version of the site (shock, horror, gasp).
Use user agent sniffing to redirect people to a separate, stripped back, text only with minimal styling version of the site. Be sure to include a link to the main site and indicate that this is a version of the site designed for older browsers.
This requires careful planning as you have to ensure that the same information is maintained on both sites and that features introduced are replicated across both sites.
This is why nobody does this and isn't something I would recommend at all. The amount of things to consider, the limitations on features you can introduce and the chance of updating one version and not the other (even with a Content Management System) is very high. Making just one of those mistakes is likely to cause you more problems than not implementing this at all.
Conclusion
HTML5 introduces many great features for accessibility.
Regions for navigation are one of the biggest wins.
By designing to older standards you will likely end up with a site that is less accessible.
For example, a lot of WAI-ARIA attributes don't work in modern browsers, never mind in older browsers. Trying to fall back to using WAI-ARIA attributes is not going to work.
What about an accessible and easy to use layout? IE6 was the days of tables for layouts because CSS was so limited with positioning. (want a sticky navigation bar? Good luck implementing that!)
To provide 'best effort' I would use a HTML5 shim to at least fix the layout for things like IE7 and IE8, IE6 just isn't feasible.
Another argument is security. How on earth are you meant to write secure JavaScript that is IE6 compatible. Heck try finding a single piece of information alive on the internet today on 'how do i fix this problem in IE6'. Perhaps your solution here is to just not use JavaScript at all. (and yes someone will argue progressive enhancement allows you to use JavaScript, but then you have JavaScript errors which would then mean you fail WCAG under 'Robust').
Oh and did you know that you can't even use <style>*{position:relative}</style><table><input></table> as that will crash the browser?
As a final thought on this rant part, Windows 98 will run IE9 and NVDA. So we cannot make the argument that people may not have the financial resources to upgrade as NVDA is free. We could argue they do not have the technical knowledge on how to upgrade, at which point all I could say is write an article on the site on how to upgrade and redirect people there maybe? It gets a bit silly at that point as to where you draw the line.
How to win the argument with your boss / help them get the spec changed
Your boss is in a bad position but probably doesn't have the 'firepower' they need to persuade the spec to be changed easily.
Here is a simple way for them to win the argument:
WCAG 2.1 AA is the minimum legal standard that we can build this site to without risking getting sued.
This is impossible while maintaining compatibility with IE6 and without compromising on accessibility features.
The cost of getting accessibility wrong, coupled with the additional development cost associated with trying to develop to such an old standard makes this infeasible.
Couple that with the likelihood of developing a application with massive security flaws that could make the site vulnerable I would highly recommend we change the minimum requirements to IE8.
tl;dr
The oldest browser you realistically need to worry about is Internet Explorer 9. Even then you are being generous with your compatibility requirements. Do not try and develop a site that works in every browser ever encountered since 2001 (yes IE6 was 2001), you will break things for more people trying to accommodate people who do not want to upgrade (Windows 98 will run IE9 and NVDA).
Do not attempt to support IE8 and below as you will actually end up making decisions that will negatively impact accessibility.
If you can create a HTML5 valid and CSS3 valid website that is WCAG 2.1 AA standards compliant then you are already more accessible than 99% of websites in the world.
You're not asking the right question.
Users of what I build may be different than the users of what you build. To one audience, it may not matter if the site only loads on current browsers. To another audience, it may be the only thing that matters.
Additionally, some sites outright require newer browser features to function... no web-based fallbacks are available. Also, there are current browsers that don't support much of anything (i.e. Safari, Lynx, etc.) so it's not necessarily a matter of age... but capability.
The question you should be asking is, how do you make the decision of what to support and what not to support. Short of pointing you at your analytics and logs, this isn't a technical question, but a business question.
I hope this question is on-topic for StackOverflow. I have seen many comments here that a lot of web developers scrollbar customizations are non-standard and not yet approved by the powers that be (W3C.org). My philosophy is to design to the standards Issued for Use by the Industry Organization that guides web standards and specifications because a properly, dependable, working website is what my users want.
Approved scrollbar customization standards that the W3C.org has approved. Where can I get that standard?
If I am off subject again, could you possibly get me some answers first, then pass me to the Red Queen for off with the head?
Thanks Community.
The "standard" Scrollbars CSS Module - Level 1 is in its early stages of adoption and that would be the only one matching your requirements.
Until it's implemented, you're limited to non-standard CSS scrollbar styling support.
Another option (the only production ready one, really) is to use a plugin which basically replaces the scrollbar mechanism with custom HTML elements.
Most of them have trouble with at least one mobile device type (either on IoS or on Android) and the sane solution is to detect it and simply disable the plugin for that case.
Note 1: while W3C support is a very wise thing to look for when choosing how to build your page, it doesn't mean much without browser support. In theory, if Chrome refuses to implement something today, considering their market share is above 60%, they simply won't and nobody can do anything about it. But your clients will require their page to work in Chrome.
However, much of Chrome's popularity comes from strictly sticking to web standards so far, so it would be safe to assume they will continue to abide by them.
Note 2: I recommend this article. It's well written, quite informative and up to date on the current state of scrollbar customizations.
tl; dr: making website for biological researchers. Are these guys apt to use IE8?
I'm developing a website that will act as a reference for biology researchers. I'd like to implement loads of HTML5 and CSS3 if I can. But I can't spend forever developing it though, and fixing websites for IE8 takes too long, especially with the heavy reliance on SVG elements I have planned. With such a user base (researchers), would it be safe to drop support for IE8 and below? I've heard that it's mostly banks and airline companies that use IE <= 8, but I've never come across an actual statistic, other than that global usage of IE8 is around 10%, which is a bit high for my taste.
The short answer is, of course, "it depends", but some things you might consider:
-Who benefits from people using your site? If it's you who wants them to use it, then the onus is more on you to make their lives easier by supporting whatever browser they use (most ecommerce sites would fit this category). If there's less value to you and you're genuinely just trying to be helpful by producing a valuable tool for you particular research community, it'd probably be more reasonable to expect them to update if they care enough.
-How much effort would support be? If it's little extra effort, then just do it, but for what you've described it sounds like support would be very difficult. If it's going to take 5 times as long to support 10% more people, I personally wouldn't bother.
-What sort of age are they? Not always true, but generally speaking younger people will tend to use more recent browsers.
In your position, I'd try to ask 10 or so people who you'd expect to use the site what browser they use. If only 1 or 2 people would be affected, I'd ditch IE8 support, and make sure the site falls gracefully back to a page explaining why they aren't able to use it and how to update their browser.
Points to consider:
Many people who use IE8 may also have other browsers installed as well. (choice of browser isn't an 'either-or' option)
How about making your site semi-functional for IE8 rather than entirely non-functional? If parts of it don't work, explain that to the user, but don't stop them using the bits that could work for them.
There are fall-back options (polyfills) for IE8 that allow you to do some modern browser features, including SVG -- see here. They won't work as well as modern browser, but they might make it possible to support IE8 a bit more than you think, without too much extra work on your part.
If your resource is useful enough, and the IE8 users can see what they're missing, it might push people to upgrade in order to use it.
Surely a group of intelligent people (scientists, researchers) would be sufficiently technically literate that they'd at least know about alternative browsers, even if they are still using an old PC that originally came with IE8. With luck, your target market may have fewer IE8 users than the general population.
One of the projects I am currently working on has customer requirements for IE7 and 508 compliance. This customer currently uses JAWS version 9 and is making requests which I am told are impossible without a newer version of JAWS which supports WAI-ARIA. For example:
Accessible, 508 compliant Ajax Loading Indicator
Accessible, 508 compliant Ajax Pagination
Before I come back and tell them that they need to upgrade to a newer version of JAWS (from Freedom Scientific's website, WAI-ARIA is supported starting with version 10), I would like to be armed with as much information as possible to make a convincing argument. First of all, is IE7 capable of conveying ARIA information to JAWS (I've seen claims of ARIA support starting with IE8, but nothing explicitly stating it doesn't work with IE7)? If so, is it only to a limited extent? Supposing the answer to this question is yes and the degree of support is sufficient, are there big differences in support between JAWS versions 10, 11, and 12 which I should know about? Perhaps this will is a good bar to meet: given the requirement for IE7, what is the minimum version of JAWS required to apply ARIA in order to solve the two questions linked above.
I know there are a lot of questions jammed in here, but I believe they worked together as a single question: please give me an overview of the varying degrees of support for WAI-ARIA between IE7 and different versions of JAWS; and to what extent can these solve the customer requests linked above.
Thanks! And even if you can't address all of the elements of this question, I would be grateful for any information you can share.
You seem to be equating 508 compliance with support for WAI-ARIA? AFAIK 508 doesn't dictate the use of ARIA.
While ARIA has been designed to overcome the many difficulties of making dynamic web apps accessible, some old hacks that it's designed to replace still more or less work. Also because it is a relatively new technology there is limited support in anything but the latest browsers/Assistive tech.
To have an AJAX progress indicator and pagination accessible with-out ARIA is not straightforward but usually you can get it working one way or another by forcing Focus to the updated parts of the page and using hidden (off-left) text to give screen reader users some verbal directions or hints. The trick being this has to be done is such a way that JAWS will go back and reload it's DOM rather that it's cached version of the page. JAWS 9 is better at this than previous versions.
If you google around you should be able to find various ways to do this.
My adice to you is hire an Accessibility Consultant for a couple of sessions otherwise you are going to be stumbling around in the dark, they'll also be able help you talk to your client and suggest Design changes if it is all looking too complicated to be done in an accessible way.
"First of all, is IE7 capable of
conveying ARIA information to JAWS"..
etc
Browsers don't send ARIA information directly to JAWS, they notify the accessibility layer of Operating System which just interpret the messages as standard operating system accessibility messages. The Assistive technology (JAWS or whatever) are just (hopefully) listening for these system messages.
I can’t speak to Chris Bentley’s suggestion of using off screen text to provide hints to screen readers. While I assume this would work I’ve never seen it done on a website. I’ve also never dealt with internal apps designed to be 508 compliant and have next to no web development experience. I second Chris’ suggestion of hiring a consultant who has experience in this area. I don’t know what the differences are between Jaws versions and WAI-ARIA support. I know Jaws 10 does at least offer some WAI-ARIA support under Internet Explorer 7. I just went to http://news.yahoo.com with Jaws 10 and was able to use the ; key to move from landmark to landmark. You can run multiple versions of Jaws without a problem on the same machine, I currently have Jaws 10, 11, and 12 installed. This should allow you to test different versions of Jaws if you can't find documentation that spells out the differences.
WAI-ARIA support is available starting in IE8 and Firefox 2+. Concerning screenreaders, use NVDA instead of JAWS. It's free and works great with Firefox. In fact, the Mozilla foundation has granted funding to NVDA to improve the NVDA screen reader. They work great together.
While browsing with Chrome, I noticed that it responds extremely fast (in comparison with IE and Firefox on my laptop) in terms of rendering pages, including JavaScript heavy sites like gmail.
This is what googlebook on Chrome has to say
tabs are hosted in process rather than thread.
compile javascript using V8 engine as opposed to interpreting.
Introduce new virtual machine to support javascript heavy apps
introduce "hidden class transitions" and apply dynamic optimization to speed up things.
Replace inefficient "Conservative garbage colllection" scheme with more precise garbage collection scheme.
Introduce their own task scheduler and memory manager to manage the browser environment.
All this sounds so familiar, and Microsoft has been doing such things for long time.. Windows os, C++, C# etc compilers, CLR, and so on.
So why isn't Microsoft or any other browser vendor taking Chrome's approach? Is there a flaw in Chrome's approach? If not, is the rest of browser vendor community caught unaware with Google's approach?
Chrome's approach is difficult to write, and requires forethought from the developers. IE and Firefox are both attempting to move to a process-per-tab model, but due to backwards compatibility are not able to transition quickly. Chrome, being an entirely new browser build on a clean rendering engine (WebKit), was easier to write in this way.
They have crossed over from a web browser as a tool to view web pages, to a tool optimized to work for web applications. There may be some flaws in this initial release, but they are changing the game.
IE8 uses a similar individual process per tab module, though they do not use a single process per tab, but instead spread all tabs across a process pool.
#pix0r but they added a little thing in the bottom right corner so you can expand the text box any direction you want, which I love because I use a wide display and prefer to type in a wider screen.
Thats actually a WebKit feature, Chrome just inherited it.
Virtually all of these features existed in other browsers before Chrome. IE8 had process isolation for tabs. Firefox / Safari had most of the JavaScript stuff. Most browsers do their own memory management.
Chrome has a few unique features (hyperrestricted render processes, etc) which are difficult to put into other browsers due to add-on/application compatibility concerns.
The primary thing Chrome has going for it is an extremely hardcore focus on minimalism and high-performance. By focusing on these as their competitive advantages, they can appeal to users who find this area of focus compelling.
As time passes, I'm sure you will see the homogenization of features as the browsers attempt to one-up each other.
In the meanwhile, I still stick with Firefox over Chrome for the simple reason that Firefox is (i) non-profit and has a (ii) huge addon community.
Addons such as NoScript and AdBlockPlus are almost essential for me.
One chink in Chrome's armor is the fact that it renders these darned textareas on StackOverflow are so small that it's making my eyes bleed!
One chink in Chrome's armor is the fact that it renders these darned textareas on StackOverflow are so small that it's making my eyes bleed!
Yeah. I mentioned this on uservoice and got declined because the current size is evidently the default under webkit. Every other site I've tried with Chrome that uses textboxes to compose content manages to have a decent sized font. The default definitely doesn't work, but there's obviously some way to override it. Jeff needs to fix this!
Edit:
Jeff was nice enough to point out how to fix this problem yourself.
#pix0r but they added a little thing in the bottom right corner so you can expand the text box any direction you want, which I love because I use a wide display and prefer to type in a wider screen.
I also wanted to point out that Google completely built Chrome from the ground up, with the exception of using webkit, so they have some of the advantages of not having to not deal with old-code. And of course there is the INSANLELY cool/smart developers.
The biggest chink I've found is its lousy proxy support compared to IE, FF and Opera. So it's pretty much useless at work, render pages at random, and requesting authentication for the proxy, where the others pass it seamlessly.
That said on my home machine it works great, if it wasn't for the OTT EULA I'd use it now.
thing2k
One "flaw" about Chrome is that it uses more memory upfront than all of the other browsers. I'm just guessing that this is due to the overhead associated with all the separate tab management.
After it's been open for some time, however, it doesn't use more memory than other browsers.
Many companies play a game of "What's the least we can do to get the leg up?" Marketing creates a laundry list of features needed to be better than the competitors. Project management ensures engineers stick to those features for fear that the project will exceed the time allocated... which of course it will. There's not a whole lot of room in such a system for a big picture leap-ahead. The incremental improvements you see in products, and browsers, is a consequence.
You have to keep in mind that Microsoft primary business is Rich environement (GUI) Application. Web tool is a threat to them as it is platform independant (not promoting they main product).
Of course the IE team probably had figured something like that but... Microsoft definetly won't invest a lot of money in IE if what they are selling is a Rich application platform.