| This 53 message thread spans 2 pages: 53 (  2 ) > > || |
I try my best to make my pages accessible to everyone but sometimes it's just not possible to do that and get the desired effect. If that means that 3 people a year are not able to get the full experience of my pages then so be it.
Does it really matter? Should we care?
For one, there is always the possibility a post may come up in a search out of context and even though you've heard it a million times, it may not be obvious to whoever finds it. There's nothing more annoying than finding a solution, spending hours getting it to work for you, then discovering it only works in IE, or your site requires accessibility and it fails.
I am on the fence with this one, I also agree that 99.99% of people don't know what it is, hence leave it on the default setting.
However rocknbil is right, no page should rely on JS to work properly. I find that <style> tags inside a <noscript> can easily make things permanently visible that would otherwise be hidden.
Apart from that, using the current techniques your script should be completely hidden, no more than 1 line of HTML! It should quietly attach itself to the page, to 'enhance' it's function, rather than being the function.
I try my best to make my pages accessible to everyone but sometimes it's just not possible to do that and get the desired effect.
With the advanced DOM capabilities today, there is very little that can't be done by starting with a more basic approach, accessible to everyone, and then enhancing that (either by totally replacing certain DOM elements or by modifying existing ones, etc.). In some cases the pure method might be more difficult to grasp, but I've never found an inaccessible method that couldn't be re-written to be accessible.
Does it really matter? Should we care?
|For one, there is always the possibility a post may come up in a search out of context and even though you've heard it a million times, it may not be obvious to whoever finds it. |
If you type "http://www.google.com" into NN1 you're going to get the following message;
|No Viewer Configured for File Type: text/html |
That's also a good point and again something I didn't think of. Another good reason to start a thread like this. :)
And about the whole Target thing... I haven't got a clue what you guys are talking about. Off to do some Googling.
[edited by: Trace at 6:58 pm (utc) on Oct. 9, 2007]
Ahhh Foti. I knew you'd reply to this one!
|At some point down the line, HTML became the norm |
[edited by: zCat at 8:26 pm (utc) on Oct. 9, 2007]
First, allow me to say my comments here, as always, are just shared recommendations of what I have learned over the years. Use them or not, it's your choice.
With G-maps it's easy, one way is to do a screenshot of the map
<div id="my_map"><img src="my_screenshot.gif"></div>
The saving grace with G-maps is they're not really vital content and you would (should) probably have alternate content somewhere else on the page defining the location anyway.
I do not see any difference at all between these two statements:
"This web site is optimized for Internet Explorer version xyz."
If you look at it that way, it reveals the old rule, you shouldn't dictate the user's environment for them.
YES WE SHOULD
|Does it really matter? Should we care? |
"I cant find how to change my settings". Ok, is under "MY ACCOUNT", and "SETTINGS", but, as is a interactive menu, some people (a lot) just cant click on it. Some markets have more users like this than others. So, sometimes having JS or not is NOT the problem, but the freedom of "tricky" interaction we, or the client want.
Ok, some people in my case complain about some "usability" simplicity, as the design looks too simple showing almost every link on a menu... but I reduced A LOT the number of emails asking "where is..." "how can I..."
Some ajax apps are a pain.... on the back button of the browser... and showing always the same page with changing content...
And some of those stat packages check if the browser is JS capable, not necessarily enabled.
We must all immediately check our websites and make sure that people with TTY output, Mono-herc and other limited pallette graphic display and all other devices capable of reproducing data in fixed form may access our data, further, all data must pass validation established by Google, Inc.
Further still; we must insure that all data transmits and displays in reasonable time and manner for those using Morse Code encoded telegraph transmission and 300bps cradle modems and that transmission can be established by devices using non-touch-tone clicks. The doctrine of "Knock Three Times on the Ceiling, Twice on the Pipe" shall be the lowest acceptable denominator.
We must also make sure that every bit of text is available in all languages known to man. In cases where the interchange of language is only accomplished via visual signals, audible sounds, scratches on stones, trees or other non-standardized character based language elements, reasonable effort must be made to provide translation services.
All ecommerce capabilities must be able to accurately calculate exchange rates from all known currencies, and in the case where bartering is the norm, we must establish a rate for exchange of beads, livestock, unmarried offspring, land or indentured servitude.
Shipping rates must be available to any point on the globe, and by all common carriers indigenous to the buyer's region. In cases where, for example a package may travel by mule, carrier pigeon or other beast of burden, disclaimers regarding dependency on the animals health, season of year and breeding status must be taken into account.
All methods employed by site must pass stringent spidering, crawling, ranking and algorythmic changes established solely by Google, Inc., and all such methods must be kept up-to-date with all changes established by Google whether by internal company memo, public announcement, or other means public or private.
Failure to comply with any of these mandates may result in system operators being sued for monetary damages due
those for whom accessibility has been denied, or removal from the internet solely at the discretion of Google, Inc.
You have been warned!
I read somewhere something like "if you want more reach, try to design for most of the people".
In my "market" and with my competitors I see prizes very often to sites with JS, AJAX, and so on... ok, fabulous... now check their rankings, link depth already on SE, reach, stats, how many people stay there on the site and how much actually say "wow, thats useful I will bookmark it" instead of "what a nice tricks and movements" (and close).
what a shame.
There are add-ons like NoScript to allow users to deny it by default and getting the right what is essentially run code on their computer will be hard from those visitors.
Also NoScript changes the behavior of the <noscript> tagadn disallows redirecting to other pages (as it's (ab)used by webmaster to send the visitors away from their pages to irrelevant error messages)
Though that figure will obviously vary by market.
It is not as simple as thinking you are losing 3% of your potential visitors. You are losing 3% of the entire market which is a much larger figure.
And that is, as already stated by other posters, if your site is even findable. If spiders can't navigate the site fully, you'll do proportionately less well in search engines.
lexipixel wrote "make sure that people with TTY output, Mono-herc and other limited pallette graphic display" - hopefully that was in jest, but you should try to avoid obstructing people who have colour-blindness or contrast perception impairment.
A couple of weeks ago I saw a site which used near-identical red/green indicators in the same position for a yes/no response, with unhelpful tooltips - only the colour changed. Let's just hope that sort of web designer doesn't ever move into traffic light design... do web 2.0 designers study other design work like older webmasters did, or are all old design ideas irrelevant because, hey, it's web 2.0?
Just like there are designers that insist on making 100% Flash based sites, there will be designer that make 100% AJAX sites. However those that are sane will always make a fallback to non-flash, non-ajax technologies.
It's not that difficult to make non-ajax fallbacks if you know what you are doing. However if you are addicted to using other people's code that doesn't have that ability, well then you are stuck, aren't you.
lexipixel wrote "make sure that people with TTY output, Mono-herc and other limited pallette graphic display" - hopefully that was in jest..."
Of course it was, (in jest --- somewhat)...
A year ago I wouldn't design a site that could not be viewed on 640x480 display, and I would only use JS for non-critical elements of the site.
JS is useful, and 90%+ of browsers can handle it now, (most users at significantly higher than 640x480).
Unlike others who insist on 100% accessibility, I shoot for 90%. There is no such thing as "100% accessible", no matter how hard you try -- the day after you finish coding, a new device, protocol, "standard" or other element of web design will fall into fashion, and some of those people will not be able to [see/hear/use/access] the site you "finished" yesterday.
Yes, you can stay up coding 18 hours a day, attempting to please all of the people all of the time -- but you are rowing against the tide.
I would rather have 90% usability -- with rich features, ease of use, simplified coding and processes and anything else I can gain for those 90% -- the competition is welcome to cater to the 10% who are non-standard.
BTW - I have immediate family members with severe disability, so the politically correct "everything needs to pass ADA" crowd get no mileage from me. My brother is a hemi-plegic (paralyzed over 50% of his body -- inside and out), and has been for 20 years. When he first became disabled he wanted me to install grab-bars up and down the walls of the entire house. My logic said: If I give him these "crutches" to lean on, he will not fit in with every day life since there are no grab bars in most places.
As do designers, at some point you need to realize that you just can't satisfy every one. Designers have to make a decision when they start a new project; do we aim for IE4+ & NN4+ sacrificing design for compatibility or do we set the bar a little higher and go for IE6+ & FX1.5+ and get the best user experience from our product.
Same with screen resolutions, do we cater to everyone and design for 640x480 - or do we better satisfy the other 99% and get a better product out? (or in lexipixels case, a 3x3 stone tablet and a chisel)
Again, the same can be said in this case, do we lower the quality of our product for everyone so that 1% of people can access our information? I still believe this is ridiculous. It makes absolutely no sense to lower our standards to satisfy that 1 in a hundred and make the other 99 miserable.
So my competitors can take that 1% of my business with my blessings and I hope they do well with it. I'll be sitting on a beach drinking a Margarita with the money I'll be making from the 99% of the business that I have a firm grasp on.
Boy am I glad that people can't turn off HTML in their browsers :o)
There has to come a point when we have to make the painful transition to new technologies. AJAX, for example, has been attacked for various reasons. Sure, I have been annoyed by the "back button" issue that arises on AJAX sites, but that's just habit and old habits die hard.
We should rethink the web and how it functions. AJAX type sites will be the future. You will see a lot more pages that will function like applications, such as Google Apps. It takes some getting used to, but it's clearly where we're headed. We don't use floppies anymore (yea, some of you do ... some people still have outhouses). No more VHS, welcome DVDs ... umm wait, I mean HD-DVD, or is it Blu-ray? Hmm! ;o)
Anyways, we can't wait to progress until every Plain Jane and Joe Schmo catches up to 2007 ... and yes, TVs can now show programs in color.
Will be painful, yes. Will be losing some customers, perhaps. Will be prepared for the future, you betcha. Just hurt a lot of people's feeling with this message, boy, don't I know it.
Umm, no ma'am, we don't use the telegraph anymore. But you can have this really cool iPhone ;o)
|There has to come a point when we have to make the painful transition to new technologies |
Agreed, but that doesn't always mean bigger, more colors, more animation.
A significant part of the growth in browsing over the next 5 years is going to come from mobile devices. Even basic phones have web browsers now - and they're being used, especially in high-growth areas in the third world without landlines/ISPs.
So keeping up with new technologies can mean making sure the site is simple anough to be usable on such devices, rather than adding more of everything.
Simple design is much harder than complicated design. But lasts better.
"...AJAX type sites will be the future..."
As I said, I avoided JS and only used it for simple one-lines that could do something I could not easily do any other way -- and only "things" that would not detract from the experience if JS was not available on the user's end.
Since AJAX depended on JS and I also considered AJAX too complex to code (not "difficult", just requiring too many disciplines, (HTML, JS, CSS, DOM and a back-end scripting language), I avoided it also.
This year I embraced both.
The best argument I saw for using AJAX was a simple link on an eBay page. For years, I would do complex searches on eBay and save them as "Favorite Searches".
To save a search required:
1. click the "Save this search" link
2. be taken to a separate page with options, (e.g.- recieve emails when new items matches the search, give the search an easy to remember name, add a note).
3. After saving, I was taken to "My eBay" searches page where I would click the newly created search to get back to where I was before step 1.
One day, I hovered my mouse over the "Save this search" link -- deciding if I should save it or not....
After a few seconds, a CSS hidden div appeared with the form to save the search -- I completed the form, clicked save, and the div disappeared.
Not only had my user experience been greatly improved, but eBay just saved thousands of bytes of data transmission by not having to display (4) complete pages. (And the "Back button" issue made no difference at all -- in fact, I was glad that it still brought me back to the page I was on previous to saving the search).
As a programmer, (and someone who used to write a lot of offline ".EXE" type applications), I find it simple to pop an Ajax window open and display a small bit of data, rather than repaint the entire screen and interrupt the application flow -- the bandwidth reduction is just icing on the cake.
..also on the AJAX "Back Button" issue -- if you watch average users interaction with a browser, you'll find many don't use the [BACK] button at all -- they expect to find all navigation on-site and in the viewport.
| This 53 message thread spans 2 pages: 53 (  2 ) > > |