Re: [WSG] I need a professional eye.
The site is www.purencool.com I caught a border:hidden in one of the h1 elements. Not wanting to sound like a fool so I googled it first to see if this is something I have not learned to use after all these years writing CSS, but I find no references. The design is clean, pleasant to look at, but the jagged curve image spoils it. It looks more bevel than curve, I think it will echo well with your logo if it's smooth curve. And why is that emptiness between left column and main content? White space is important element for a design/layout, emptiness isn't. Also, the menu items at footer section is best centralized vertically within the blue bar. tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Accessibility does not matter!
Thanks to people who have commented via blog and email. If nothing else I think I have sparked up a healthy debate about accessibility whether I am right or wrong. I will try and reply directly to remarks made by various individuals: @Paul Novitski Harsh wording Sir. That's all I can say. As a UXD working on 12 million target user Government portal the only thing I can try and be is broad, emphatic and deep, but I also develop apps in my own spare time and have a wife and child to feed and maybe live a bit of life in spare minutes. In first instance 'full accessibility' is a must. In second, it might not be. That's my point. Where can I read your masterpieces and thoughts by the way? @Luc Glad we agree. ;-) @Peter Mount To some extent we are playing with fire developing however we are developing. Sometimes (within Intranet systems specially) we are specifically told by the client to develop for IE6/IE7 and not care about other browsers as the client is trying to save cash on testing (dev and UAT) and so on. Bottom line, there are circumstances within which 'playing with fire' is what the client wants. @Chris F.A. Johnson That page is accessible, it just looks shit in the browser you tested in (whatever you have used there - would have nice to have test environment details). I don't care. Content is visible and accessible. I am not intending to support everything under the Sun under my blog. @Mark Harris Plagiarism will get you nowhere. ;-) @Oliver Boermans IE6 / Intranets reply. Today we make a decision to use JQuery as a framework for AJAX/JS. In two year JQuery gets dropped by browsers for whatever reason and browsers no longer support it. We are once again 'playing with fire'. Do you know exactly what future holds? How do we know that everything we are doing today will not have to be re-written in 2-3 years time to be compatible. HTML4 -- HTML5 is a perfect example of a case where technology will imply some changes need to be made in order for things to keep up with time. Just a thought. Thanks for replies once again. Back to coding now. On Sat, Jan 30, 2010 at 12:13 PM, Lesley Lutomski ubu...@webaflame.co.uk wrote: I also agree with this, and I have a problem with someone whose view on accessibility seems to focus on the technologies, not the people using those technologies. I have a modern browser (Firefox 3.5) with full support for Javascript, Flash, etc. I also have disabilities which make it very difficult for me to use some sites which employ those technologies. If you want me, and people like me, to visit your site for more than a few seconds, then I suggest you focus on whether we can access it, not whether our computers can! Lesley Oliver Boermans wrote: On 30/01/2010, at 11:04 AM, Peter Mount i...@petermount.com wrote: Even with closed systems like intranets you're playing with fire if you don't have regard for accessibility. Agreed. Web applications built ‘for' closed intranets are the reason so many corporates still have IE6 installed. There are perfectly good selfish reasons why companies ought to consider accessibility. It's about ensuring things just work. Ollie *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** -- Jason Grant BSc, MSc CEO, Flexewebs Ltd. www.flexewebs.com ja...@flexewebs.com +44 (0)7748 591 770 Company no.: 5587469 www.flexewebs.com/semantix www.twitter.com/flexewebs www.linkedin.com/in/flexewebs *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Accessibility does not matter!
Good afternoon Jason, It was foretold that on 30/01/2010 @ 16:57:27 GMT+ (which was 14:57:27 where I live) Jason Grant would write: snipped a bit JG @Luc Glad we agree. ;-) Just to make myself clear: i don't agree with your point of view: the quoted text was to illustrate the motive that one should be using accessibility. -- Regards, Luc _ http://www.dzinelabs.com Using the best e-mail client: The Bat! version 4.2.6 with Windows XP (build 2600), version 5.1 Service Pack 3 and using the best browser: Opera. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Accessibility does not matter!
On 30/01/2010 16:57, Jason Grant wrote: @Paul Novitski Harsh wording Sir. That's all I can say. As a UXD working on 12 million target user Government portal the only thing I can try and be is broad, emphatic and deep, but I also develop apps in my own spare time and have a wife and child to feed and maybe live a bit of life in spare minutes. In first instance 'full accessibility' is a must. In second, it might not be. That depends on your definition and understanding of full accessibility. Are we talking WCAG 1, WCAG 2, ...? @Peter Mount To some extent we are playing with fire developing however we are developing. Sometimes (within Intranet systems specially) we are specifically told by the client to develop for IE6/IE7 and not care about other browsers as the client is trying to save cash on testing (dev and UAT) and so on. Bottom line, there are circumstances within which 'playing with fire' is what the client wants. That's a different argument to what you make in your blog post, which does not mention clients at all - just the argument that in those situations accessibility is irrelevant. There is a difference. @Oliver Boermans IE6 / Intranets reply. Today we make a decision to use JQuery as a framework for AJAX/JS. In two year JQuery gets dropped by browsers for whatever reason and browsers no longer support it. We are once again 'playing with fire'. Do you know exactly what future holds? How do we know that everything we are doing today will not have to be re-written in 2-3 years time to be compatible. HTML4 -- HTML5 is a perfect example of a case where technology will imply some changes need to be made in order for things to keep up with time. Just a thought. So, what are you getting at? Yes, let's make the intranet completely inaccessible and just wait until an employee with disabilities gets hired, then redo it all? Looking at your comments on the blog, I note we should be able to get away with single A accessibility and a solid mobile solution instead. Accessibility is not a matter of getting away with anything. It's about providing the best solutions for the widest possible audiences. You seem to have a dichotomy of UX vs Accessibility, for some reason. And again you seem to be stuck on the no JavaScript mindset. Is THAT really the crux of your argument? Are you hung up on WCAG 1? Is your blog post simply boiling down to I want to use JavaScript, but WCAG 1 won't let me, but for UX it's great, and I can't be bothered to do a no-JS parallel solution? If so, WCAG 2 of course allows JS, if it's used correctly. So I can finally understand the principles behind WCAG2.0. I get the impression that you still don't, I'm afraid. By saying that accessibility does not matter in certain situations, you're implicitly saying that WCAG 2 doesn't matter. P -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com | http://flickr.com/photos/redux/ __ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] I need a professional eye.
I tried your calculator example on Mac OSX 10.6 in Firefox, Safari and Chrome and it did not work in any of them. Also, why duplicate functionality that already exists in jQuery. You can get fully functional fading and a plug-in calculator that work across all current browsers and all operating systems using jQuery. John On Fri, Jan 29, 2010 at 11:36 PM, PurencoolGmail purenc...@gmail.comwrote: Hi everyone, I need a professional eye. I have been developing this site for two weeks (with help from this email group) and now that I think I have finished. All I want to know is there too much css? The site is www.purencool.com Any feed back would be great and you don't have to be nice. -- bJohn Cullen/b purencool.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] Accessibility does not matter!
On Behalf Of Patrick H. Lauke Sent: Saturday, January 30, 2010 10:22 AM To: wsg@webstandardsgroup.org Subject: Re: [WSG] Accessibility does not matter! @Oliver Boermans IE6 / Intranets reply. Today we make a decision to use JQuery as a framework for AJAX/JS. In two year JQuery gets dropped by browsers for whatever reason and browsers no longer support it. We are once again 'playing with fire'. Do you know exactly what future holds? How do we know that everything we are doing today will not have to be re-written in 2-3 years time to be compatible. HTML4 -- HTML5 is a perfect example of a case where technology will imply some changes need to be made in order for things to keep up with time. Just a thought. So, what are you getting at? Yes, let's make the intranet completely inaccessible and just wait until an employee with disabilities gets hired, then redo it all? Also, an employee with no disability today could have one tomorrow. -- Regards, Thierry | www.tjkdesign.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Accessibility does not matter!
On Sat, 30 Jan 2010, Jason Grant wrote: Thanks to people who have commented via blog and email. ... @Chris F.A. Johnson That page is accessible, it just looks shit in the browser you tested in (whatever you have used there - would have nice to have test environment details). The only environment detail that matters is the font size. You haven't allowed for users with a different default font size -- and that *is* a matter of accessibility. I don't care. Content is visible and accessible. I am not intending to support everything under the Sun under my blog. Why not? It's more work to prevent it working everywhere than it is to *let* it work everywhere. -- Chris F.A. Johnson http://cfajohnson.com === Author: Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress) Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress) *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Accessibility does not matter!
@Chris F. A. Johnson Once again, the site only looks rubbish for most part and is still accessible with larger font size. How do you propose overcoming this issue with fixed width layouts. I don't want my site to look rubbish like your for 98% of my users. Also with CSS switched off the site's content is perfectly visible with whatever default font size. @Thierry Koblentz 'Could' is not something we should be developing for. We need to know who we are developing for, otherwise it's a bit of a hit and miss. @Patrick H. Lauke 'Full accessibility' to me means a fully functional site with JS switched off, with all visual goodies in place of course (contrast, flexible font size and so on) according to WCAG1.0, to which we have so far been working. When web apps context comes in, meeting these WCAG1.0 becomes a massive burden and extra work. Clients issue - I am usually not developing for Santa Clause. Clients essentially rule the game and set the constraints which I need to meet. I am not going to invent constraints or drop anything that client requires. If they tell me 'code for IE6 only' I will tell them 'but IE8 is already in use and IE9 is round the corner, so IE6 is way beyond it's use by date, so I would not recommend what you suggest under any circumstances' and they tell me that I should not worry, I am not going to be an idiot enough to be pushing my issue as it tends to simply piss people off and make me look bad in the eyes of everyone. JS issue. When writing this article for most part I *was* thinking about JS vs. no-JS matters. To implement a proper progressively enhanced solution for a complex web app it really does take lots of thinking and additional (possibly complex) JS/AJAX code for it to work. I haven't got that time to do it with the app I am currently developing. Coincidentally can someone send me a complex-ish web app using JS that has been 'properly developed' with regards to accessibility? Anything in the wild will do. Yahoo used to taut Flickr as one, but it isn't. On Sat, Jan 30, 2010 at 8:56 PM, Chris F.A. Johnson ch...@cfajohnson.com wrote: On Sat, 30 Jan 2010, Jason Grant wrote: Thanks to people who have commented via blog and email. ... @Chris F.A. Johnson That page is accessible, it just looks shit in the browser you tested in (whatever you have used there - would have nice to have test environment details). The only environment detail that matters is the font size. You haven't allowed for users with a different default font size -- and that *is* a matter of accessibility. I don't care. Content is visible and accessible. I am not intending to support everything under the Sun under my blog. Why not? It's more work to prevent it working everywhere than it is to *let* it work everywhere. -- Chris F.A. Johnson http://cfajohnson.com === Author: Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress) Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress) *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** -- Jason Grant BSc, MSc CEO, Flexewebs Ltd. www.flexewebs.com ja...@flexewebs.com +44 (0)7748 591 770 Company no.: 5587469 www.flexewebs.com/semantix www.twitter.com/flexewebs www.linkedin.com/in/flexewebs *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Accessibility does not matter!
@Chris I couldn't resist this Sir. Your site: http://chess.cfajohnson.com/ Uses two tables on the front page. The first should be a dl and both are missing thead section. Poor accessibility. It's also an unusual practice to be putting inline images into an h1, but at the very top you have h1aimg construct going on. HHmmm. Anyway. Back to my shell script. ;-) On Sat, Jan 30, 2010 at 10:00 PM, Jason Grant ja...@flexewebs.com wrote: @Chris F. A. Johnson Once again, the site only looks rubbish for most part and is still accessible with larger font size. How do you propose overcoming this issue with fixed width layouts. I don't want my site to look rubbish like your for 98% of my users. Also with CSS switched off the site's content is perfectly visible with whatever default font size. @Thierry Koblentz 'Could' is not something we should be developing for. We need to know who we are developing for, otherwise it's a bit of a hit and miss. @Patrick H. Lauke 'Full accessibility' to me means a fully functional site with JS switched off, with all visual goodies in place of course (contrast, flexible font size and so on) according to WCAG1.0, to which we have so far been working. When web apps context comes in, meeting these WCAG1.0 becomes a massive burden and extra work. Clients issue - I am usually not developing for Santa Clause. Clients essentially rule the game and set the constraints which I need to meet. I am not going to invent constraints or drop anything that client requires. If they tell me 'code for IE6 only' I will tell them 'but IE8 is already in use and IE9 is round the corner, so IE6 is way beyond it's use by date, so I would not recommend what you suggest under any circumstances' and they tell me that I should not worry, I am not going to be an idiot enough to be pushing my issue as it tends to simply piss people off and make me look bad in the eyes of everyone. JS issue. When writing this article for most part I *was* thinking about JS vs. no-JS matters. To implement a proper progressively enhanced solution for a complex web app it really does take lots of thinking and additional (possibly complex) JS/AJAX code for it to work. I haven't got that time to do it with the app I am currently developing. Coincidentally can someone send me a complex-ish web app using JS that has been 'properly developed' with regards to accessibility? Anything in the wild will do. Yahoo used to taut Flickr as one, but it isn't. On Sat, Jan 30, 2010 at 8:56 PM, Chris F.A. Johnson ch...@cfajohnson.com wrote: On Sat, 30 Jan 2010, Jason Grant wrote: Thanks to people who have commented via blog and email. ... @Chris F.A. Johnson That page is accessible, it just looks shit in the browser you tested in (whatever you have used there - would have nice to have test environment details). The only environment detail that matters is the font size. You haven't allowed for users with a different default font size -- and that *is* a matter of accessibility. I don't care. Content is visible and accessible. I am not intending to support everything under the Sun under my blog. Why not? It's more work to prevent it working everywhere than it is to *let* it work everywhere. -- Chris F.A. Johnson http://cfajohnson.com === Author: Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress) Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress) *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** -- Jason Grant BSc, MSc CEO, Flexewebs Ltd. www.flexewebs.com ja...@flexewebs.com +44 (0)7748 591 770 Company no.: 5587469 www.flexewebs.com/semantix www.twitter.com/flexewebs www.linkedin.com/in/flexewebs -- Jason Grant BSc, MSc CEO, Flexewebs Ltd. www.flexewebs.com ja...@flexewebs.com +44 (0)7748 591 770 Company no.: 5587469 www.flexewebs.com/semantix www.twitter.com/flexewebs www.linkedin.com/in/flexewebs *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Accessibility does not matter!
On Sat, 30 Jan 2010, Jason Grant wrote: @Chris I couldn't resist this Sir. Your site: http://chess.cfajohnson.com/ Uses two tables on the front page. The first should be a dl and both are missing thead section. Poor accessibility. I agree. That's a very old page that I haven't yet got around to fixing up. It's also an unusual practice to be putting inline images into an h1, but at the very top you have h1aimg construct going on. There's nothing wrong with unusual. HHmmm. Anyway. Back to my shell script. ;-) -- Chris F.A. Johnson http://cfajohnson.com === Author: Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress) Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress) *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Accessibility does not matter!
On Sat, 30 Jan 2010, Jason Grant wrote: @Chris F. A. Johnson Once again, the site only looks rubbish for most part and is still accessible with larger font size. But even that is unnecessary; there's no good reason not to have it look good for everyone. How do you propose overcoming this issue with fixed width layouts. Don't use fixed-width layouts. http://cfaj/cfajohnson.com/webdesign/fixed-width/ I don't want my site to look rubbish like your for 98% of my users. What, pray tell, looks like rubbish? What doesn't work for 99% of viewers? Also with CSS switched off the site's content is perfectly visible with whatever default font size. One would certainly hope so! Now take it that tiny step further and make it work for everyone no matter what their default font size. -- Chris F.A. Johnson http://cfajohnson.com === Author: Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress) Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress) *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Accessibility does not matter! - ADMIN
ADMIN This discussion is quickly deteriorating into name calling, finger pointing, etc. Please return to the discussion, and be respectful of each other - regardless of your differences of opinion. Thanks Russ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Accessibility does not matter!
Jason, I would not feel comfortable working for a client with such disregard for accessibility. To extend your argument if the client asks me to break the law does that make it OK? There is a real business need to have even intranet systems that are accessible. As for your assertion in the following line: If nothing else I think I have sparked up a healthy debate about accessibility whether I am right or wrong. I think there is a difference between sparking healthy debate and being a troll. -- Peter Mount Web Development for Business Mobile: 0411 276602 i...@petermount.com http://www.petermount.com On 31/01/2010, at 3:57 AM, Jason Grant wrote: @Peter Mount To some extent we are playing with fire developing however we are developing. Sometimes (within Intranet systems specially) we are specifically told by the client to develop for IE6/IE7 and not care about other browsers as the client is trying to save cash on testing (dev and UAT) and so on. Bottom line, there are circumstances within which 'playing with fire' is what the client wants. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] Accessibility does not matter!
From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Jason Grant Sent: Saturday, January 30, 2010 2:14 PM To: wsg@webstandardsgroup.org Subject: Re: [WSG] Accessibility does not matter! So, what are you getting at? Yes, let's make the intranet completely inaccessible and just wait until an employee with disabilities gets hired, then redo it all? Also, an employee with no disability today could have one tomorrow. @Thierry Koblentz 'Could' is not something we should be developing for. We need to know who we are developing for, As I suggested in my post, ignoring accessibility pretending you know your audience is a mistake. Because any user can become disabled one way or the other (because of a broken wrist for example). otherwise it's a bit of a hit and miss. I'd say narrowing your target audience increases your chances of missing. -- Regards, Thierry | www.tjkdesign.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Accessibility does not matter!
@Thierry I don't see how breaking a wrist has much to do with accessibility? My article does not say 'break all accessibility rules' if you can. It basically tries to say that a given advanced app solution (such as Google Calendar) requires JavaScript support to work in a semi-meaningful way. This fact usually impacts users accessing the site/app with some sort of an assistive technology or a technology with shitty JavaScript support (I used BlackBerry Bold 9000 as an example of common tool used to access the app I am currently working on). From UXD point of view we want to provide target users with highest level of usability through devices they are using. That way we increase profit and ROI. Under WCAG1.0 we would be coding for 'universal accessibility' and maybe degrade overall usability of the solution, while not providing optimal support for BlackBerry (as a scenario). This is all to do with lack of resources (time, money, skills, etc.). My argument is that 'high selective accessibility' is better than 'regular universal accessibility' if that sum-up makes any sense. This is all driven by the nature of highly varied user agents on the market now, compared to what was the case some 5 years ago even. Hope this makes sense. So I am by no means against as high accessibility as possible, but I think that evaluation of 'high accessibility' needs to be approached from a clever, business angle. On Sun, Jan 31, 2010 at 1:03 AM, Thierry Koblentz thierry.koble...@gmail.com wrote: From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Jason Grant Sent: Saturday, January 30, 2010 2:14 PM To: wsg@webstandardsgroup.org Subject: Re: [WSG] Accessibility does not matter! So, what are you getting at? Yes, let's make the intranet completely inaccessible and just wait until an employee with disabilities gets hired, then redo it all? Also, an employee with no disability today could have one tomorrow. @Thierry Koblentz 'Could' is not something we should be developing for. We need to know who we are developing for, As I suggested in my post, ignoring accessibility pretending you know your audience is a mistake. Because any user can become disabled one way or the other (because of a broken wrist for example). otherwise it's a bit of a hit and miss. I'd say narrowing your target audience increases your chances of missing. -- Regards, Thierry | www.tjkdesign.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** -- Jason Grant BSc, MSc CEO, Flexewebs Ltd. www.flexewebs.com ja...@flexewebs.com +44 (0)7748 591 770 Company no.: 5587469 www.flexewebs.com/semantix www.twitter.com/flexewebs www.linkedin.com/in/flexewebs *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Accessibility does not matter!
Jason your subject line is Accessibility does not matter!. If you're going to make a statement like that then I suggest you make a list of real world examples to back up your claim. Plus how can an app be useable if some people don't find it accessible? That is the flaw in your argument and it is a huge flaw. You are implying that an app can achieve greater usability by using features which in turn deny access to those users who can't use those features. How does this increased usability benefit those people who can't use it? -- Peter Mount Web Development for Business Mobile: 0411 276602 i...@petermount.com http://www.petermount.com On 31/01/2010, at 12:16 PM, Jason Grant wrote: @Thierry I don't see how breaking a wrist has much to do with accessibility? My article does not say 'break all accessibility rules' if you can. It basically tries to say that a given advanced app solution (such as Google Calendar) requires JavaScript support to work in a semi-meaningful way. This fact usually impacts users accessing the site/app with some sort of an assistive technology or a technology with shitty JavaScript support (I used BlackBerry Bold 9000 as an example of common tool used to access the app I am currently working on). From UXD point of view we want to provide target users with highest level of usability through devices they are using. That way we increase profit and ROI. Under WCAG1.0 we would be coding for 'universal accessibility' and maybe degrade overall usability of the solution, while not providing optimal support for BlackBerry (as a scenario). This is all to do with lack of resources (time, money, skills, etc.). My argument is that 'high selective accessibility' is better than 'regular universal accessibility' if that sum-up makes any sense. This is all driven by the nature of highly varied user agents on the market now, compared to what was the case some 5 years ago even. Hope this makes sense. So I am by no means against as high accessibility as possible, but I think that evaluation of 'high accessibility' needs to be approached from a clever, business angle. On Sun, Jan 31, 2010 at 1:03 AM, Thierry Koblentz thierry.koble...@gmail.com wrote: From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Jason Grant Sent: Saturday, January 30, 2010 2:14 PM To: wsg@webstandardsgroup.org Subject: Re: [WSG] Accessibility does not matter! So, what are you getting at? Yes, let's make the intranet completely inaccessible and just wait until an employee with disabilities gets hired, then redo it all? Also, an employee with no disability today could have one tomorrow. @Thierry Koblentz 'Could' is not something we should be developing for. We need to know who we are developing for, As I suggested in my post, ignoring accessibility pretending you know your audience is a mistake. Because any user can become disabled one way or the other (because of a broken wrist for example). otherwise it's a bit of a hit and miss. I'd say narrowing your target audience increases your chances of missing. -- Regards, Thierry | www.tjkdesign.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** -- Jason Grant BSc, MSc CEO, Flexewebs Ltd. www.flexewebs.com ja...@flexewebs.com +44 (0)7748 591 770 Company no.: 5587469 www.flexewebs.com/semantix www.twitter.com/flexewebs www.linkedin.com/in/flexewebs *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Accessibility does not matter!
@Peter Title of my article is 'Accessibility does not matter?' (the question mark is very intentional there). To address your second point I will go back to the app I am currently developing. It needs a lot of JavaScript to improve usability of the tool and a progressively enhanced solution would be so far from the JavaScript solution that in reality they are like 2 different implementations of the tool. Considering this tool has already taken me 10 solid days of coding (in my spare time) without following the full progressive enhancement route and I have another 20 days solid left in order to finish the Alpha version, while I cannot envisage this tool being used by a person with a non-JS support browser. Why should I spend time coding a progressively enhanced solution for this when I don't see this tool ever being used by a disabled person of any sort? Just to clarify, the tool will work perfectly with JS on, while it will still work without JS on, but the experience will be very poor in my estimation (so it would still be possible to use it, but a blind person would not enjoy using this at all I would say). On Sun, Jan 31, 2010 at 1:35 AM, Peter Mount i...@petermount.com wrote: Jason your subject line is Accessibility does not matter!. If you're going to make a statement like that then I suggest you make a list of real world examples to back up your claim. Plus how can an app be useable if some people don't find it accessible? That is the flaw in your argument and it is a huge flaw. You are implying that an app can achieve greater usability by using features which in turn deny access to those users who can't use those features. How does this increased usability benefit those people who can't use it? -- Peter Mount Web Development for Business Mobile: 0411 276602 i...@petermount.com http://www.petermount.com On 31/01/2010, at 12:16 PM, Jason Grant wrote: @Thierry I don't see how breaking a wrist has much to do with accessibility? My article does not say 'break all accessibility rules' if you can. It basically tries to say that a given advanced app solution (such as Google Calendar) requires JavaScript support to work in a semi-meaningful way. This fact usually impacts users accessing the site/app with some sort of an assistive technology or a technology with shitty JavaScript support (I used BlackBerry Bold 9000 as an example of common tool used to access the app I am currently working on). From UXD point of view we want to provide target users with highest level of usability through devices they are using. That way we increase profit and ROI. Under WCAG1.0 we would be coding for 'universal accessibility' and maybe degrade overall usability of the solution, while not providing optimal support for BlackBerry (as a scenario). This is all to do with lack of resources (time, money, skills, etc.). My argument is that 'high selective accessibility' is better than 'regular universal accessibility' if that sum-up makes any sense. This is all driven by the nature of highly varied user agents on the market now, compared to what was the case some 5 years ago even. Hope this makes sense. So I am by no means against as high accessibility as possible, but I think that evaluation of 'high accessibility' needs to be approached from a clever, business angle. On Sun, Jan 31, 2010 at 1:03 AM, Thierry Koblentz thierry.koble...@gmail.com wrote: From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Jason Grant Sent: Saturday, January 30, 2010 2:14 PM To: wsg@webstandardsgroup.org Subject: Re: [WSG] Accessibility does not matter! So, what are you getting at? Yes, let's make the intranet completely inaccessible and just wait until an employee with disabilities gets hired, then redo it all? Also, an employee with no disability today could have one tomorrow. @Thierry Koblentz 'Could' is not something we should be developing for. We need to know who we are developing for, As I suggested in my post, ignoring accessibility pretending you know your audience is a mistake. Because any user can become disabled one way or the other (because of a broken wrist for example). otherwise it's a bit of a hit and miss. I'd say narrowing your target audience increases your chances of missing. -- Regards, Thierry | www.tjkdesign.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** -- Jason Grant BSc, MSc CEO, Flexewebs Ltd. www.flexewebs.com ja...@flexewebs.com +44 (0)7748 591 770 Company no.: 5587469 www.flexewebs.com/semantix www.twitter.com/flexewebs www.linkedin.com/in/flexewebs
[WSG] Minimal forms or marking up a search field
A practical distraction for the standardistas and accessibility gurus… Hoping tap your brain for an alternative perspective on the simple and common HTML scenario of a site search form. fieldset legendSearch this site/legend label for=searchKeyword/s/label input type=text id=search name=search / input type=submit value=Search / /fieldset As far as I understand it this mark-up meets the requirements demanded of such a form. Although, in striving for simplicity, there may be significant redundancy. My question regards the HTML and text used: How much mark-up can be removed without breaking it? - FIeldset / legend combination are required to meet HTML standards and provides valuable context to my mind. Am I missing anything? - Sacrifice the label and add a title attribute on the text input? fieldset legendSearch this site/legend input type=text id=search name=search title=Keyword/s / input type=submit value=Search / /fieldset - Once supported, will the new HTML5 placeholder attribute make the label redundant fieldset legendSearch this site/legend input type=text id=search name=search placeholder=Keyword/s / input type=submit value=Search / /fieldset - How many users know that they can use the Enter key to submit the form? fieldset legendSearch this site/legend input type=text id=search name=search placeholder=Keyword/s / /fieldset - The future? fieldset legendSearch this site/legend input type=search id=search name=search placeholder=Keyword/s / /fieldset Editable mark-up here http://fixee.org/paste/bxmsvue/#url=bxmsvue Redundancy can be a good thing, but where do you draw the line? Looking forward to your considered thoughts and relevant experiences. Cheers Ollie -- @ollicle *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] Minimal forms or marking up a search field
If you are looking for a simple search form (i.e. the input box into which user enters a search term followed by 'Search' submit button) you should be using something like this. label for=sSearch/label input type=text name=s id=s / input type=submit value=Search class=primary / You do not need fieldset nor a legend as they are intended for grouping form fields on more complex forms. I agree. I'd just use a DIV to wrap these form controls. -- Regards, Thierry | www.tjkdesign.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Accessibility does not matter!
Jason, I can not accept that underline text on your post is not a clickable link. Your W3C and WCAG words did not have its abbreviation. And the option at the bottom of submit button is not in a logical order, I think. :) -- Regards, Dani Iswara http://daniiswara.net/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Accessibility does not matter!
So lack of time is an excuse we can use for not using accessibility from the start? How convenient we can use that excuse for not helping potential users. Besides, every email in this thread has the title Accessibility does not matter! with the !. Interesting you can't envisage anybody needing accessibility in your target audience. What methodology did you user to determine that? Did you allow for any variables on that in the future or are you assuming nobody is going to get injured or sick or even need to start wearing eye glasses? With the following paragraph: Just to clarify, the tool will work perfectly with JS on, while it will still work without JS on, but the experience will be very poor in my estimation (so it would still be possible to use it, but a blind person would not enjoy using this at all I would say). What are you saying? It seems like you are sitting on the fence in your argument. If you're going to say Accessibility does not matter!, with the !, I'd like some more solid evidence to back up your statement. -- Peter Mount Web Development for Business Mobile: 0411 276602 i...@petermount.com http://www.petermount.com On 31/01/2010, at 1:07 PM, Jason Grant wrote: @Peter Title of my article is 'Accessibility does not matter?' (the question mark is very intentional there). To address your second point I will go back to the app I am currently developing. It needs a lot of JavaScript to improve usability of the tool and a progressively enhanced solution would be so far from the JavaScript solution that in reality they are like 2 different implementations of the tool. Considering this tool has already taken me 10 solid days of coding (in my spare time) without following the full progressive enhancement route and I have another 20 days solid left in order to finish the Alpha version, while I cannot envisage this tool being used by a person with a non-JS support browser. Why should I spend time coding a progressively enhanced solution for this when I don't see this tool ever being used by a disabled person of any sort? Just to clarify, the tool will work perfectly with JS on, while it will still work without JS on, but the experience will be very poor in my estimation (so it would still be possible to use it, but a blind person would not enjoy using this at all I would say). On Sun, Jan 31, 2010 at 1:35 AM, Peter Mount i...@petermount.com wrote: Jason your subject line is Accessibility does not matter!. If you're going to make a statement like that then I suggest you make a list of real world examples to back up your claim. Plus how can an app be useable if some people don't find it accessible? That is the flaw in your argument and it is a huge flaw. You are implying that an app can achieve greater usability by using features which in turn deny access to those users who can't use those features. How does this increased usability benefit those people who can't use it? -- Peter Mount Web Development for Business Mobile: 0411 276602 i...@petermount.com http://www.petermount.com On 31/01/2010, at 12:16 PM, Jason Grant wrote: @Thierry I don't see how breaking a wrist has much to do with accessibility? My article does not say 'break all accessibility rules' if you can. It basically tries to say that a given advanced app solution (such as Google Calendar) requires JavaScript support to work in a semi-meaningful way. This fact usually impacts users accessing the site/app with some sort of an assistive technology or a technology with shitty JavaScript support (I used BlackBerry Bold 9000 as an example of common tool used to access the app I am currently working on). From UXD point of view we want to provide target users with highest level of usability through devices they are using. That way we increase profit and ROI. Under WCAG1.0 we would be coding for 'universal accessibility' and maybe degrade overall usability of the solution, while not providing optimal support for BlackBerry (as a scenario). This is all to do with lack of resources (time, money, skills, etc.). My argument is that 'high selective accessibility' is better than 'regular universal accessibility' if that sum-up makes any sense. This is all driven by the nature of highly varied user agents on the market now, compared to what was the case some 5 years ago even. Hope this makes sense. So I am by no means against as high accessibility as possible, but I think that evaluation of 'high accessibility' needs to be approached from a clever, business angle. On Sun, Jan 31, 2010 at 1:03 AM, Thierry Koblentz thierry.koble...@gmail.com wrote: From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Jason Grant Sent: Saturday, January 30, 2010 2:14 PM To: wsg@webstandardsgroup.org Subject: Re: [WSG] Accessibility does not matter! So, what are you getting at? Yes, let's make the intranet
Re: [WSG] Accessibility does not matter!
Accessibility is: 1% of equality [1] + 99% of empathy :) Internet is invented by the West, Web-standards movement was originated in the West, all those corporates that make software, have a big influence and dominated the market (Microsoft, Freedom Scientific, Adobe...) are all from the West. Western mindset is all about freedom of *fill_in_blank* + equal access + right of use, but empathy is quick lacking the way I see it. Green business has a term, greenwashing, perhaps we should have a term for accessibilty-washing, that is, 1% of equality minus 99% of empathy, I often think that this is the reason why web accessibility is slow crawling, because there isn't profit in making accessible software, web application, websites , etc. And it's that empathy that one has that makes one willing to run extra miles to make an accessible website, but one's effort is limited, on this notion, I can understand some of Jason's argument, though I don't agree with him. Some culture in the East has the notion of empathy but lack of freedom of *fill_in_blank* + equal access + right of use, and they have to learn the Web-standards and accessibility knowledge using English and learn from the West. I am pretty certain Tim Berners-Lee on The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect includes 99% of empathy. tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Minimal forms or marking up a search field
On 31 January 2010 13:45, Thierry Koblentz thierry.koble...@gmail.com wrote: You do not need fieldset nor a legend as they are intended for grouping form fields on more complex forms. I agree. I'd just use a DIV to wrap these form controls. Thanks guys, I’m glad I asked this question. I was carrying around the idea that the required element around any inputs inside a form element was a fieldset. Seems I was wrong, any block element will satisfy the spec. So presuming we do away with the legend: div id=searchform label for=searchKeyword/s/label input type=text id=search name=search / input type=submit value=Search / /div …and assuming there are no other 'search' fields in the page we need to distinguish from. I’d like to test some further assumptions: - Some people don’t know how to submit the query without a 'Search' (or 'Go') button? div id=searchform label for=searchKeyword/s/label input type=text id=search name=search / /div Apple seems to believe the the submit input is unnecessary http://www.apple.com - Now that the legend is gone I should use the label to describe the purpose of the text field rather than what one should enter in it? Everyone knows you put keywords in a search field, right? div id=searchform label for=searchSearch/label input type=text id=search name=search / /div - Is including the keywords hint in the title attribute useful to anyone? div id=searchform label for=searchSearch/label input type=text id=search name=search title=Keyword/s / /div - Does everyone agree this is taking simplicity too far? div id=searchform input type=text id=search name=search title=Search / /div Thanks for indulging my hairsplitting. Ollie -- @ollicle *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
RE: [WSG] Minimal forms or marking up a search field
From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On Behalf Of Oliver Boermans Sent: Saturday, January 30, 2010 8:21 PM To: wsg@webstandardsgroup.org Subject: Re: [WSG] Minimal forms or marking up a search field On 31 January 2010 13:45, Thierry Koblentz thierry.koble...@gmail.com wrote: You do not need fieldset nor a legend as they are intended for grouping form fields on more complex forms. I agree. I'd just use a DIV to wrap these form controls. Thanks guys, I'm glad I asked this question. I was carrying around the idea that the required element around any inputs inside a form element was a fieldset. Seems I was wrong, any block element will satisfy the spec. So presuming we do away with the legend: div id=searchform label for=searchKeyword/s/label input type=text id=search name=search / input type=submit value=Search / /div .and assuming there are no other 'search' fields in the page we need to distinguish from. I'd like to test some further assumptions: - Some people don't know how to submit the query without a 'Search' (or 'Go') button? div id=searchform label for=searchKeyword/s/label input type=text id=search name=search / /div Apple seems to believe the the submit input is unnecessary http://www.apple.com - Now that the legend is gone I should use the label to describe the purpose of the text field rather than what one should enter in it? Everyone knows you put keywords in a search field, right? div id=searchform label for=searchSearch/label input type=text id=search name=search / /div - Is including the keywords hint in the title attribute useful to anyone? div id=searchform label for=searchSearch/label input type=text id=search name=search title=Keyword/s / /div - Does everyone agree this is taking simplicity too far? div id=searchform input type=text id=search name=search title=Search / /div I'd go with: div role=search label for=search_querySearch for:/label input type=search placeholder=Keyword(s) id=search_query name=search_query size=20 input type=submit value=Submit /div It won't validate though. You could also throw autofocus in there in case you plan to focus on the field when the page loads. -- Regards, Thierry | www.tjkdesign.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Accessibility does not matter!
I whole heartily agree with you Tee, and more importantly with Tim Berners-Lee, the Internet as a whole was invited for the people to share information, and how can information be shared if accessibility is limited, even on intranet's if the system is built from the beginning to be widely accessible. When I first started learning about writing code for Standards Compliancy, and made sure I followed the outlines, I soon found myself writing in that manner automatically, it's just a matter of learning. And in this day and age, what decent developer builds software for web or otherwise does it without learning new techniques. If those developer's are not willing to adapt to the needs of consumers, they should steps aside, and take up another profession. Sorry, but I get beaten out of jobs myself due to these amateurs, only to have those client's come back to me, stating they went somewhere else 'cos it was cheaper, and they haven't been given the accessibility or editable options I discussed with them. Also, to the person in the previous comments (don't remember who it was, I do this via email), that stated something about when jQuery is no longer supported in Browser's. You need to do a little homework before making such claims. jQuery is a JavaScript framework, hence it's JavaScript, which is support in almost every Browser, and JavaScript won't be getting dropped from Browser's for a very long time, and in fact it's been around before it was implemented and support in Browser's. Being Netscape in fact. If anything should or would get dropped, it should be these bulky have to install into the user's OS third party add-ons, such as Flash, Silverlight, and so on. On a personal note Tee, you seem to be of the mind of following or have heard of Esoteric Agenda? tee wrote: Accessibility is: 1% of equality [1] + 99% of empathy :) Internet is invented by the West, Web-standards movement was originated in the West, all those corporates that make software, have a big influence and dominated the market (Microsoft, Freedom Scientific, Adobe...) are all from the West. Western mindset is all about freedom of *fill_in_blank* + equal access + right of use, but empathy is quick lacking the way I see it. Green business has a term, greenwashing, perhaps we should have a term for accessibilty-washing, that is, 1% of equality minus 99% of empathy, I often think that this is the reason why web accessibility is slow crawling, because there isn't profit in making accessible software, web application, websites , etc. And it's that empathy that one has that makes one willing to run extra miles to make an accessible website, but one's effort is limited, on this notion, I can understand some of Jason's argument, though I don't agree with him. Some culture in the East has the notion of empathy but lack of freedom of *fill_in_blank* + equal access + right of use, and they have to learn the Web-standards and accessibility knowledge using English and learn from the West. I am pretty certain Tim Berners-Lee on The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect includes 99% of empathy. tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Accessibility does not matter!
On Sun, Jan 31, 2010 at 1:16 AM, Jason Grant ja...@flexewebs.com wrote: @Thierry I don't see how breaking a wrist has much to do with accessibility? Broken wrist = inability to use a mouse. If your site/intranet/app is not keyboard-accessible, how is that person supposed to use it? Now you've exposed your naivety, I suggest you let the good people of this thread educate you so you can create better work in the future. :) - Matthew *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
