News & Gossip

Another IE6 boycott

4 Comments

I know almost every blogger wrote about this subject (lately all complaining about IE6 still being used by common users) – but this time I think we should take all this to the next level and start doing something about it.

I admit I don’t usually have contact with the final clients or have access to their websites stats – working as a freelancer made me lose contact with the real world and soon I started to believe that IE6 is slowly dissapearing. My sites’ stats show that Mozilla “rulz” when it comes to browsers and slowly, over the years, I began hoping that maybe one day I won’t have to code for IE6 anymore. The release of IE8 should have been the final stroke.

I was wrong. On most of the websites I code Internet Explorer is the master and mostly IE6 (I saw IE 5 too). We’re talking about brochure sites for small companies from Western Europe targeting users over 30years. Not IT sites read by coders who probably have all the existent brosers installed on their computers.

So it’s time to do something – we cannot talk to everybody asking to upgrade but we can add some custom message into our code to encourage users to upgrade. It’s safe, it’s free and it’s recommended. Starting from simple messages/ icons in the footer/sidebars of the websites you code to a more “extreme” solution like “IE6 Upgrade Warning Script” asking you to upgrade your browser and choose from IE8, Mozilla, Safari, Opera & Chrome. I think this kind of script scares people but maybe a small percentage will actually click.

I know I did not re-invent the wheel, coders wrote about this a long time ago – but no common user is reading IT blogs or actually talking about browsers at the pub – so I think a lot of messages shot blank by addressing to the wrong users. Asking permission from the final client to use their site help people move on from IE6 towards something better is my idea.

I look forward to reading about yours.

Accessibility, HTML5

A third way to write and validate forms – HTML5

4 Comments

After writing an accessible form in XHTML and validating it with a PHP server side script & after that with a Mootools client-side script, I write today about a third way of approaching the subject – using future-to-come HTML5 (by saying that, I really hope to be able to use it waaaay before 2011).

The beauty consists in having all the above mentioned validation inside HTML code:  we’ll have

  • input type=”email” for email addresses
  • type=”url” for urls
  • type=”date” and “datetime” for date fields (usually done with JS calendars until now), or “month”, “week”, “time”
  • type=”number”  for number only inputs
  • accessible sliders, with type=”range”
  • datalists
  • ability to add extra validation conditions after writing the tag, like: required, read-only,disabled, autofocus, a minimum value, a maximum accepted value/length

The code for our simple contact form will be much lighter:

<form action="index.php" method="post" name="contactform" id="contact">
 
<label for="name">Name <span>(required)</span></label>
<input  tabindex="1" type="text" name="name" id="name" required />
 
<label for="mail">Email <span>(required)</span></label>
<input  tabindex="2" type="email" name="mail" id="mail" required />
 
<label for="phone">Telephone</label>
<input tabindex="3" type="text" name="phone" id="phone" />
 
<label for="message">Message</label>
<textarea tabindex="4" cols="30" rows="10" name="message" id="message"></textarea>
 
<button tabindex="5" type="submit" name="submit" id="send">Submit</button>
 
</form>

The result will be a much easier way of writing and validating forms in an accessible manner, without adding extra load/code with PHP/JS scripts. All you have to do is place “required” to all the required fields and use the above mentioned minimum value, maximum accepted value, etc to control the user’s input.

The entire list of types and useful tables with the methods that apply to each state can be found on W3C site

The problem right now is the inabilityof the browsers to work with lots of HTML5 features. And the future does not look good either. So far the only browser that supports the new forms is Opera 9.5+.  Internet Explorer 8 and below is not compatible and IE9 probably won’t be either (we’re talking about 2010).  Chrome 2+, Safari 4+ will partially support some features while Mozilla won’t do it even in its 4.0 version (due to launch in 2010).

Now, the same contact form we used to play with, but written in HTML5, will look the same but behave much more nicely (the code is lighter too). It’s saving us a lot of time and headaches and it’s much more user friendly.  Play with the new example – in Opera 9.5+ – and drop us a feedback if you consider that the subject is interesting enough to come back with more code-examples.

Check the Spanish version of this post:
Una tercera manera de escribir y validar formularios – HTML5

Accessibility, Php

Basic copy-paste accessible contact form

A good way to learn about accessibility is through examples and discussions. In this post I will try to translate the WCAG sometimes-hard-to-get rules into a copy-paste real contact form example.  You can check the test link, download the code and/or keep reading a bit more.

As I mentioned before, contact forms are in great need of special markup in order to be accessible. And it seems that there’s always room for improvements – in case you have suggestions or your approach is different,  I’d love to hear from you.

My suggestion is a simple 4 fields contact form with PHP server side validation. After the user submits the required information the page is reloaded and new messages are displayed depending on the user actions.  Of course you all know that the form needs

<label for="name">

tag and some sort of validation – everybody is writing about the need to display in an accesible way which fields are required and also the error messages (usually indicating the missing fields)  – but few actually offer a simple straightforward code to copy-paste in our sites.

The stylesheet is very light – we have to style the form – but the novelty is a class for the fields that are required and not yet filled. This way after we validate we return the error message with links to the missing fields but we also hightlight them for a more usable and intuitive experience. The PHP part is reading the inputs, checks them and sees if the required ones were filled.  A thank you message is displayed in case the user filled all the required fields.

The number of fields can easily be increased but don’t forget to validate them -when someone understands how the form works and which were the accessibility elements that were included then buiding more complex forms becomes just a matter of typing.

Check the Spanish version of this post:
Un básico copia y pega de un formulario de contacto accesible

Accessibility

Common sense accessibility 2.0

When it comes to accessibility, every coder is a small guru. On the websites where I bid for projects everybody is an accessibility and usability expert (including myself, I admit).

Altough these rules exist for quite a while there are coders who find difficult to implement them – so I am trying to find here what are the tricks that you use in writing your code to make it accessible.  For example, although writing semantic code helps (a lot !) it is not always enough.  Some try to view their pages with CSS and images disabled, some don’t.  Some of us have tricks that we do not want to share to other coders.  Some of us share. We’re not all gurus, right? Someone has to start from somewhere.

So if you have something interesting to say, add your own rules here.

Let’s start with basic common sense:

  1. write semantic and valid code – use correct tags while trying to satisfy Google’s needs – adapt the tags to the context
  2. use lists for navigation and for consecutive link blocks
  3. write accessible forms : use labels, server-side validation, even fieldset where necessary. Should I use type=”image” with alt text instead of submit? I don’t know….I like submit. Camino does not :((
  4. use the skip to content or skip navigation links. Everybody say you should….
  5. using a .wai class to hide text that might help screen readers – some people use display:none (not so good), some use negative indent.
  6. provide transcriptions for video files (does Google do that for YouTube?), alt tags, longdesc tags, explanation for graphics (the coders who built Forex sites did that?), audio CAPCHA (do you do that???)
  7. other common-sense ideas – use em or percent instead of px (although Mozilla is a very good fellow and knows how to increase em, px, % and also images), use big text on buttons, appropriate contrast colors,  no animated gifs/blinking/flickering elements, align text on the left side,  don’t use “click here” links cause they ALL are click here…
  8. write accessible tables : use th scope=”row” and “column”, id and header attributes to associate data cells with header cells,  use summary and caption to give extra clues about the content of the table (altough usually tables are preceded by headings and short paragraphs of text). Use tables to display data only.
  9. provide a search function  – although I build small brochure sites and I don’t embed search in them.  Do you? For small sites?
  10. provide buttons to increase font size.  Sometimes  I do, sometimes I don’t, depending on what clients ask. I believe that people who have special needs know the CTRL + combination and use it, the A-, A+ buttons seem to me like a bit redundant.  Maybe I’m wrong… Also I do not provide a button to increase the line-height and other white spaces, I set the line-height in CSS to be bigger that the default. Is it good, is it bad? You tell me, I’m keen to know.

Beside these rules there are lots more, some that make sense and are used, some that I don’t remember here. I’m having a short list of elements that I don’t use mainly because I do not have contact with them and I forget (or want to forget that)  they exist.  I’m still learning about more sensible elements for the  people in need so maybe I’m ignoring some details.

So, the next accessibility rules are not my favorites:

  1. use altkeys for navigation – a lot of people still argue about it, I’m waiting to see who wins
  2. use title for frames – it shoud say “avoid frames”, but for who’s using them….use titles
  3. target=”_blank” issue – there is still a lot of arguing about forcing the user to an action that he/she does not want. It’s common-sense too, but for the coders not respecting the above rules this is too …. in-depth. For me, it’s like somebody adding sugar in my coffee when I mentioned that I like it black. What if I have diabetes?
  4. use the focus indicator – I recognize I don’t bother too much to style it, although I do tab sometimes through navigation links or form elements. 🙁

That’s it for now, these are some basic rules I have in mind when I code.  I do try to visualize the site with the CSS/images disabled but I am aware that this is not enough. The simple fact that I’m trying to improve my knowledge is my excuse. But I know it’s not enough and if you have similar sets of rules that guide you please share them here – to guide everyone who is trying to learn something useful.

Ohhh, I forgot: use image replacement techniques, it’s a great invention 🙂

Check the Spanish version of this post:
Accesibilidad con sentido común 2.0