According to W3Cschools just 17% of users still use IE6.
Source
Also their statistics show that just 4% of users have a resolution of 800x600 or lower.
Source
At what point do I neglect users that refuse to update in order to improve the experience for rest of the users?
How much do you think the content of the web page effects this threshold?
I support IE6 and 1024x768 because that is what most of my target audience (education) is using.
I suggest gathering some statistics before you decide what you will/won't support.
You should cater to your audience as much as possible.
At the point where you are reaching a sufficient portion of your target audience that the cost becomes too great to make up for the additional little bit you gain by supporting a lessor-used browser.
For most sites, 17% is too much to drop for the little bit of work required to support it.
But IE5 is small enough, and the compatibility issues large enough that it doesn't make sense to support it.
If you're running a site oriented to a technical audience you might be able to drop ie6 as very few of your target audience would be turned away, and the additional work to support them is greater than the value they represent to your site.
Regarding screen resolution - keep in mind that more and more users are experiencing the internet through mobile devices. This is a question that you can only answer by looking at your content/application, and your userbase, and making a judgment call.
For the most part, big sites support a wide range of resolutions and devices transparently, but you may only need to support one once you look at your audience and application.
Keep in mind that many users don't browse with the browser maximized so screen resolution is a relatively useless statistic.
If you use a cross browser toolkit like GWT, dojo and so forth, you should not have to neglect anyone. That's exactly what they are made for.
I guess it does depend on your site's audience and not on stats of w3cschools. According to the site Firefox is 46% (march 2009). For my site, 63% of the trafic is generated by ff. So you can assume quite a difference for your own site.
If you make money with the site, look at the numbers and depending on your user conversion rate decide if it is worth making the site available for ie6 and the expected return on investment.
If your site generates revenue from clients, then
Sum(Revenue from 86% users) > 3 * Sum(Revenue from 14% users (who use IE6))
else
every client is king.
If you don't make money from your site, I would definitely not do any extra work to support IE6. If it were a technical site, I wouldn't even bother with IE at all, just stick to standards (of course, it probably would work in IE 7/8).
If you make money from your site, consider this. Would you be okay with 17% less profit?
I wouldn't neglect IE6 users yet. Not all users will necessarily be in a position to upgrade, e.g. some users may be accessing your site from their workplace where the IT department mandates a particular version of IE.
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 a quick question and It might not be the right place the ask it but I hope someone can help me becuase im curious.
I'm creating a one-page website whit a lot of style (isnt designed webfriendly and uses a lot of images) this isnt a big problem because we believe we're aiming at a more design branche who most likely have kind of good pcs with a pretty ok connection to the internet and the site is sized down a lot of mobile.
But still I wonder what people recommend. my site is currently 2.2mb on loading (is there a website where you can check this btw? I just made a guess by calculating the file sizes of images etc.) I can still optimize a lot but I think going under 1mb is being a hard task. is this good enough or is there anyway who has experienced it isnt?
thanx in advance
You shouldn't worry about the size of your website (especially since you know your target audience) if the user experience doesn't suffer. However, you should optimize everything you can without sacrificing the design. Google's Page Speed might help you a lot. They even have the total size calculator you wanted. There are tons of similar tools available online as well.
Also, read this about last year's website size trends: http://www.theglobeandmail.com/technology/tech-news/bloated-web-pages-costly-for-smartphone-users/article9355125/
According to the website HTTP Archive, which regularly studies the top 10,000 most-visited sites online, the average web page now weighs in at about 1.3 megabytes, up about 35 per cent in the last year.
UPDATE
Inspired by #pwdst's comments, I'd like to add that if you want support for mobiles, tablets, etc... there's no need to sacrifice the look of the main site - you can use media queries and practically serve a different presenation to those users. Of course, you can go even further and make a different website for them (usually a subdomain).
If you use dev tools, for example in Chrome, you can see the number of requests and total transferred data under the "Network" tab. To accurately replicate the experience of your users, you should do this with an empty cache - "Incognito" or "Private" tabs can be a great way to do this in most browsers. It's also worth remembering that the experience when testing locally will be drastically different from that when the effects of latency and upstream bandwidth come into play.
Be extremely careful about assumptions regarding users if you want to maintain usability. "Good enough" is extremely contextual, it may be "good enough" for a user on a desktop, laptop or premium tablet on a solid DSL connection - but anything but on a Edge or 3G connection on a phone. Wherever possible assumptions should be backed up by analysis of user agent strings from server logs, or from analytics software such as Google Analytics. It's also worth remembering that you may have relatively few mobile or tablet requests, not because mobile or tablet users don't want to visit the website - or choose to visit using another device, but because it is difficult, slow or even impossible to use on their device of choice. This case study from an engineer at YouTube illustrates how customers were being completely excluded from the site.
In general the page should be as small as possible, and you may want to look at lazy loading in addition to optimisations, which will help initial rendering time - in fairness though your estimated size is not much larger than the internet archive average page weight of 1681kB as at January 15th this year. Don't forget that other resources can also use a lot of space - JavaScript makes up 274kB of that average - and it's not clear if you have factored that into your estimate. Aggressive use of caching will help return visitors and minimise the data transfer required in these circumstances.
I always try to consider if you can justify the page weight cost against functionality. What is the objective of visitors to your site? Does the added functionality or imagery help this sufficiently to justify the performance cost. Many performance orientated developers are now actively setting a page weight budget but this is harder for single page apps where you cannot be as granular with resources.
I would recommend using Image Pre-loading which can help your page loading times, even when its large.
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.
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".
With today's modern mobile phones, is it still worth programming the mobile version of your site in WML?
Most mobile browsers even a few years old can manage to do okay in regular HTML. With WML, you are obviously given more control over what is displayed and what isn't with less fear of it not working on a particular device, but today, with all the advancements in mobile browsing (iPhone, Android, etc) is it really best to go this route?
I am wondering if the best option is instead to go with an HTML4 document that has a few more bells-and-whistles than what WML can do, but not quite the glorified super-spectacular AJAXified interface that one might design for a modern desktop browser.
Yes, I know, this is objective and has a lot to do with site audiences and how far I want to extend support. To put a scope to this question, my main concern here is whether foregoing WML for HTML is going to devastate a huge chunk of my audience and leave them completely stranded.
Edit for Dr.Dredel's point: the site would NOT be used by an SMS campaign or anything of the sort. The website is an event booking site for pickup games for hockey. Some users currently browse to it on their mobile phone to sign up for different sessions.
Do both. There's no reason to ignore the browser string and display the same markup for every device. WML is simple enough that you can use template styles (which you should be using already) to provide a custom experience for all your useers, regardless of the device they use.
Those with bare cell phones will get a usable interface that meets their needs, while those with PDA phones get a nicer interface with more options, and those with the iPhone might even get the eye-candy iPhonophiles really bought their phone for.
If you can't do that, for whatever reason, go with the least common denominator to gain the greatest visibility and usage - that's what's going to make your site successfully and useful enough that you can afford to use a real templating system and move towards the ideal state. This is likely WML, although even older phones were ok with very simple HTML, it just has less control and ease of use features.
-Adam
I think the primary problem with this question is that it fails to identify what exactly it is that you're offering your users, which would instruct who, demographically, would find your site.
If your site is arrived at via SMS based links (through some global marketing campaigns) then you need to try to reach the widest possible audience, since almost all phones will allow a user to click within their SMS client and then launch whatever browser option is on the that phone.
If, on the other hand, you have a site which needs to be browsed over to manually, then there's a reasonable expectation that most people simple won't bother on their crappy pseudo browsers, because even the act of inputting the url is a fairly large hassle.
I would say that if you're dealing with option B you're pretty safe just delivering an experience that is tailored for a browser like Netscape 1.1 (just dust off whatever you were doing in 1995 and you're good to go! :)
The vast majority of mobile phone users have a phone that was purchased within the last few years, and any users that have a phone older than that are unlikely to want to use the internet from their mobile. Personally I think you would be better of making a high-end 'AJAXified' site with all the bells and whistles and a standard XHTML-MP site that would be accessible to most users.
You should use XHTML-MP for mobile versions of sites. You'll get better continuity with the non-mobile version and it will work with more (particularly newer) devices