As a web developer, it is tough to do web design which is compatible with IE6. Is it required to make webpages compatible with css?. I heard the usage of IE6 is low.
My question is, whether I should still check compatibility of the webpage that i make, in Internet Explorer 6?
First, It depends on your audience. (This is where analytics come in handy)
For instance, a design focused blog might be able to avoid caring about Internet Explorer 6, as they can expect a large number of their users to be running the latest browser.
On the other hand, a website that focuses on business and accounting might need to support Internet Explorer 6, as some businesses refuse to upgrade.
Second, you must take into account that Google, many websites, and several countries have decided that Internet Explorer 6 is too horrible to support anymore. This means that you are in good company with not supporting Internet Explorer 6, and most likely you won't have too many problems.
Finally, you have to think if it is worth your time to develop for older browsers. It comes down to a cost per hour type thing, where if you could possibly be making more money doing other things than making sure your website works in older versions of browsers, you probably want to do those things instead.
No. It's almost a decade old and terrible to boot.
I suggest using http://ie6update.com/ to encourage any IE6 users to upgrade.
It depends. Every site is different. You can check your logs to get an idea of what percentage of your users use IE6.
One would love the answer to be no.
In reality the answer is: it depends on what your target market is using.
We have several large corporate companies who are slow to move and still use IE 6 as their SOE (standard operating environment).
For us the answer is yes you do.
Is part of your audience forced to use IE6? EG are your clients unable to upgrade? If it's a general site (ie not being developed for in house use) forget IE6. However if people within your company who will be using the site are not able to upgrade to IE6 then you'll have to provide some support.
Even then, much better to talk to the tech support guys and try and get them to upgrade the company machines to something better then 6.
In my company we have corporate users who are still using IE6, so the reality is that we MUST support it for the features they are already paying for. For new features we are starting to take a hard look at a) the cost of supporting IE6 and b) is it even technically feasible to accomplish some of the more advanced things that we want to to within the browser.
On a recent project we took the same approach mentioned by #Pwninstein and explicitly state that IE6 is not supported. BUT... $$ talks and if we have a customer who wants to pay for IE6 then who am I to refuse their money :).
Bottom line, like everyone else has stated: it depends. Or just wait until April 8, 2014. That's when MS drops support, then we can all feel good about not supporting it.
Personally, I would say no - larger companies, like Google, have recently abandoned support for IE6 as well. The fewer websites that explicitly provide support for it, the quicker it will be phased out completely by the users' own choice.
Do you make [a lot of] money from ie6 users? If true, make it ie6 compliant.
My question is "Why not?". Why do you want to leave this audience (what if it is small). I saw many people who still use it. So my answer is "yes".
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 have learned alot of standards in the past few months and now i see that some websites are using features from the working drafts and it got me confused because i checked then few features from standrds and working draft and i could see that standards arent 100% implemented and that working drafts have very good implementation as well almost as standards (transform, animation).
now, on the internet i see websites using non standardized features and it makes me wonder why if its not standard yet and its pretty bleeding edge.. thanks
The only one who can answer this question is you. This ultimately comes down to what you are doing on a per-project basis and the requirements. For example, if you are working on an enterprise software project and there are lots of users that will be running very old machines (think IE10/11) then you will need to make sure you can support those devices with the decisions you make.
If you are working on a project that is only targeting designers and personas that generally have nicer, newer machines and you are not concerned about older devices and browsers, and you think most users will have powerful machines with modern browsers, you can get away with using some much newer stuff.
It is up to us as developers to ask questions about who the intended audience is and let that shape the decisions we make.
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.
I build websites for a small-ish media company. Unfortunately, around 45-50% of our client base uses IE6, while the other half are pretty much equally split between Firefox and Webkit-based browsers, with a sprinkling of Opera users.
I start every one of my sites with a reset stylesheet similar to Eric Meyer's, with a few modificaions. I've been using the Blueprint CSS "framework" a lot recently, and it's made my life a lot easier, though I am not especially attached to it.
Roughly 60% of my development time is spent making sure the sites I create don't look incredibly different in each browser. I code for Firefox 3 then tweak from there.
Does anyone know of any stylesheets/frameworks out there that attempt to preemptively account for all of those stupid little browser quirks? I know that nothing out there can totally account for all the browser weirdness, but it would be nice to have something a little more solid to start with.
I'm working on creating my own, but it would be nice to have something to start with.
The Yahoo YUI library helps deal with a cross browser rendering issues. Namely, the Reset component (http://developer.yahoo.com/yui/reset/) will revert all browser specific rendering (margin and padding on certain elements for instance), creating a level playing field to start from when designing your site.
Take a look at YAML.
Read and inwardly digest Transcending CSS by Andy Clarke, Molly E. Holzschlag, Aaron Gustafson, and Mark Boulton.
It gives a set of techniques for dealing with those quirks you can deal with, and advice on making web sites accessible to older or less capable browsers, or those using other technologies, such as screen readers.
The fundamental thrust is on making sites that degrade gracefully.
It contains lots of links to resources that deal with these issues.
Dean Edwards' IE7 library copes with some of the Internet Explorer quirks.
Blueprint was one of the early appearances in this space, and is considered to be quite mature.
http://code.google.com/p/blueprintcss/
Here's a huge list of available frameworks:
http://www.cssnolanche.com.br/css-frameworks/
There was a lot of interesting debate in the web dev community about css frameworks at the time. Many were worried this violated some stucture/presentation seperation, and introduced non semantic class names and structure.
Some views:
http://jeffcroft.com/blog/2007/nov/17/whats-not-love-about-css-frameworks/
http://playgroundblues.com/posts/2007/aug/10/blueprints-are-not-final/
http://www.markboulton.co.uk/journal/comments/blueprint_a_css_framework/
http://peter.mapledesign.co.uk/weblog/archives/blueprint-semantics-markup-frameworks
Have you looked at the Yahoo YUI stuff? They have a cross-browser CSS Framework.