This is good news as it shows that Microsoft are no longer looking to support the past. It’s a big deal for them to take this decision and I feel that this is a clear sign that they are supporting web-standards moving forward.

This is also a great result for the few people that stood-up and constructively criticised the initial announcement. Their voice was heard.

The RNIB web access team are putting on a free event at the Westminster University, New Cavendish street campus on Tuesday 5th June at 7pm, where Shawn Lawton Henry of the W3C Web Accessibility Initiative will speak about WCAG 2.0.

I saw Shawn speak as part of an accessibility panel at SXSW06 and I was impressed that she really got across the practicalities of implementing Accessibility guidelines which is really important to anyone that’s actually going to be building accessible websites.

For more details of the topics that will be covered on the night, visit the event page and sign-up a soon as possible, capacity of the venue is limited.

The venue has been provided thanks to the support of the support of the Department of Electronics, Communications and Software Engineering

Kimberley Blessing – Co-Lead
Derek Featherstone – Accessibility Task Force Co-Lead
Dori Smith – DOM Scripting Task Force Co-Lead
Stephanie Troeth

Molly Holzschlag:

As many of you know I’ve been group lead for 2 years and I’ve been working very hard to bring WaSP into the modern world. There was a point where Steve Champeon said if you open up comments on the site at some point I will slit my wrists. increadible things have happened this year. Let’s highlight a couple of that have happened this year

WaSP Cafe – getting people together
IE7 – what an amazing experience to see a comapany that I worked for in the past, they used to joke that the moment you walked in the door you sewed your lips shut. Now they are avery forward facing company.

WCAG 2 has been a very controversial area that we are sifting through.

Opera passed the ACID 2 test

CSS is 10 years old. How many people don’t use CSS? (no hands)

And now HTML is moving forward. For those of you that don’t know theres the W3C and WHATWG and no there’s a dialogue opened up between them.

Kimberley Blessing:

Everyone in this room owes Molly a hugh debt of gratitude. (Standing ovation)

Derek Featherstone

We’ve had a number of iniatives in the ATF. We struggling with whether we could come to a consensuse over WCAG2.

These are the things we will be focusing on in the next 6 months etc.
People want more. To learn more about a topic that’s very important. We are going to be doing more conference and workshops and publishing tutorials etc.

We wrote an open letter to assistive technology to Assistive tech companies to ask them if we can work with them to make assistive technogies better. Things like test suites, so that when we’re out there doing the right thing, we will know the technology will work together.

We are going to be publishing more articles on the WaSP blog and watch what’s happening in the industry.

WCAG2 has 4 solid core principles. There are other areas that don’t meet the needs of developers. What we want to do is say we know the techniques we know development. We want to help WCAG to write techniques that are more practical for developers. There’s a lot W3C things with regard to WCAG that are a lot of good. There’s a lot of time that’s gone in to that, I don’t want to see it wasted.

We are looking to tackle some of the leftover things that happened with the last redeign of the WaSP site.

DORI Smith

I was looking back at last year’s AGM, we’ve had some big ideas. But we’ve been so darn busy. JavaScript has been huge. Last year we thought we were going to have to tell people that javaScript is a cool language. There’s still a long way to go with regard to best practices. The world doesn’t need 60 different JS libraries. Or 3 different HTML working groups.

We’ve been speaking at conferences and teaching classes. We’ve been writing books on best practices. Hopefully less books by (ed: less informed authors.)
Beginning JS by Chris Heilmann, Buillet Proof Ajax JK, PPK on JS etc.

We need help, if you write some good stuff or documentation then let us know and we will put it on the WaSP blog.

We are working with MS on the next version of IE. IE7 didn’t do a lot with JS we are going to work with them on that.

Stephanie Troeth

Education task force.

This is my first SXSW actually it’s nice to meet everyone.

Our focus has been on higher ed and colleges. We are interested in teh landscape of eductiona. In 2006 we’ve done one interview per month. The people that we interviewed are teachers. We are raising awareness. highEdWeb poster presentation by Rob Dickerson. Students are wondering why they are failed for using widely published CSS techniques. We want to do a curriculum survey so people can tell us what they are missing. Slides, info etc. We want to hear this from the teachers themselves. We want to collaborate with teachers and point to existing resources online.

We also want to look at content management systems. CMS’ often don’t produce good code. We’d like to address that this year

We need new members that can commit the energy and time. If you’re interested, contact us on the EDUTf page on the WaSP site.

International Liaison group

(slide with 35 members)

21 languages available with more coming. The ILG consists of memebers that live and work in the various contries who are evangalising Web standards. We ahve these obectives for the following year. We want to focus on outreach. Obviously english is not the language that everyone communicates in. We are going to internationalise webstandards.org

WaSP are promoting web standards via WaSP Cafes. These are organised by affiliates or by web standards group members themselves.

KB: We stole an idea from record companies. We give you the WaSP street team. Giving you ways to get involved with Web Standards evangelization.

http://streetteam.webstandardsgroup.org

We are now looking to reach out to libraries to make sure that the books that are there are up to date. We can create some bookmarks that inform the person that other books are available.

Subscribe to the RSS feed.

Questions:

…

Q: Can you talk to the CMS Vendors that highED uses?
A: (KB): This is something that comes up all of the time and we are looking to open dialogue with Education facilities.

…

Q: how do you join WaSP?
A (KB): It’s invitation only. To get involved make yourself known. Teaching, something at your company. You need to demonstrate that you are making an effort. You also need to have time available to commit to WaSP. I would say 3-4 hours a week is required. If you’re just getting started then there are other ways that you can get involved.
DF: The one caveats with all of this, is don’t do all of these things to become a WaSP do it because it’s the right thing.

Q: What about e-learning? With regard to accessible modules?
A: We’re not directly addressing this. But we are looking to address this. …
Qcont: Adobe has captivate and it allows people to create modules that aren’t accessible.
Acont (SK): Let’s talk abou this afterwards

…

Q: Is WaSP working with Adobe on Apollo.
A: No
A (cont): Actually we are starting to speak to some people.

James Craig: I’d like to address the CMS question. One of the things is that WaSP can’t put out a list of CMSs we have to remain neutral. that’s why Molly left the group lead position when she started working with Microsoft.
KB: James put that very well. A policy of remaining neutral is important.
SK: We can’t recommend one University or another. We can’t endorse a specific university.
From the floor: There are other lists out there DIR?

Q: There are some obvious crossovers with the WSG, are there some ways we can work together.
A (SK) We already are, as there are members of the WSG in the ILG. So if you don’t know about it come and talk to us.

…

I’m really looking forward to this one, and I hope that you can join us. For more information and to book your place please visit the mini-site.

Please note places are limited to 200 so please sign-up as soon as you can.

Prizes for Questions

As before at the WSG microformats event we will be holding a Q&A session at the end of the night. For every question that’s asked we’ll have a small prize, so be thinking up the questions you’d like to ask our speakers whilst they are presenting.

WSG London is now lubricated with Event Wax

For this event I’m making use of Event Wax for registration. The registration sign-up is simplicity itself. All that’s required is a name and an email address. By using Event Wax there’s no dependency on attendees being members of Upcoming.org and at the same time it makes registering for as many tickets as you need dead easy. Thanks to Patrick and Dan and everyone at eventwax for building this app, it fits the bill perfectly.

In a year the team are slowly but surely changing how they work and are moving over to using web standards and beginning to follow best practices. This article goes through some practical examples of how you can be a catalyst for change within your company.

Roadblocks to change

Based on my own experiences there two main areas to focus on. The first is your management and the second is your colleagues. If you need to get your manager to understand why web standards are important then you need to think a little like your manager does. A web manager’s role revolves around delivering projects on time and within budget, so one of the common complaints regarding adoption of web standards is that doing things this way takes longer. This can be true to some degree but this mainly occurs whilst developers get used to doing things differently.

Overcoming this barrier if it exists for you is mainly a case of increasing your knowledge and experience. Beyond that you can also attempt to show that if standards based sites consume a little more time up front then that ‘cost’ can easily be made up in bandwidth savings, easier maintenance etc. Planning a site properly will also help make a website easier to build and save time in the development phase. Planning also stops the website becoming a mess because all of the possible flaws in the design have been ironed out before the first line of code is written. This is turn makes every developer more efficient and the execution of a site becomes more like painting by numbers.

The second issue is all about turning the rest of your team on to web standards. If any of your colleagues share an interest in web standards then it will help if you can team up together. If you’re on your own then I would imagine that although it’s a daunting task you need to demonstrate the practical and simple benefits of using standards. If you’re talking to developers then it’s a case of getting them excited about techniques and skills and showing them how web standards makes websites better for all users and devices. If you are talking to designers then there are plenty of resources on the internet to help get a designer enthused into doing more with markup and CSS from CSS zen garden to showcases like CSS beauty and Style Gala.

Open to learning

If a colleague doesn’t seem to be too receptive then don’t push too hard. It’s better to move forward at a slower pace than to cause someone to become highly resistant to change. Let everyone play a part and don’t stop learning yourself. If you are trying to influence change it is very easy for your colleagues to perceive you as being arrogant or dictatorial even if you don’t mean to be, so make sure you keep your feet on the ground and don’t be elitist. If people around you are making mistakes then show them what they are doing wrong in a positive way without running them into the ground. That way you will find they will listen to you and be more open to learning.

Build your own standards

Over time as the team grows in experience of web standards and development skills, it will be possible to influence any existing coding standards your company has and to build a document that reflects the team’s best practices. This document helps to maintain consistency across the board which in turn makes it easier for developers to work with each other’s code. Best practices can also speed up considerably development time through standardising the way you do things. For example, you can prevent developers having to ‘work out’ the best way to achieve a particular job using standards every time they create a site by having common code examples. A classic use for this would be something like forms or tables. In doing this do make use of the many amazing resources on the internet and link to any articles that are relevant to your documentation. Just make sure you qualify anything you quote.

Conclusion

Bringing about change is not easy in any field and anyone that wants to get their colleagues to adopt web standards will not get instant results. It takes time, it’s very frustrating at times and it’s also very hard work. However, as small changes take place and as you start to see the results of your efforts, it’s very rewarding and this helps to fuel you on to your next goal.

Further Reading

• Converting your team
• Web Standards Are Your Responsibility

Content first

Historically I would have started a project by creating a design in photoshop, convert that to XHTML/CSS and then add content. This is not the best way. Creating a site should hinge around the content. Understanding the content helps you to do a far better job of creating the site because you are laying out the content to support the goals of the site. After the content is mapped out, the design is created to support the content framework, be it a wireframe diagram or notes on the back of a napkin.

Another benefit that comes from structuring content first (as noted by Andy Clarke of stuffandnonsense.co.uk at @media 2005), you can’t do anything until you have some idea from the client the objectives of the site and some level of content in front of you. This is a good way of finding out if the client is committed to the project.

Use the right mark-up for the job

Semantic mark-up is important. In other words the mark-up (XHTML) that you use to structure your page needs to be meaningful to the content within. Learn what each element can be used for; if you’re not sure of the best way to mark up some content then research and find the best way. Be aware that html has it’s limitations but with thought you can work around those limitations without compromising semantics.

Hand-code everything

Using a text editor to create XHTML and CSS will help you to learn about html elements. As you hand-code you will need to know how to construct a page correctly using the right mark-up as everything is up to you. Code-completion whilst it can be helpful, is actually harmful to your learning ability. Hand-coding has the other advantage that you are in control of everything you write, if the code you create isn’t correct you can’t blame it on the tool!

Build your site with accessibility in mind

Creating a site using web standards already assists you in making your site accessible, not only to those with disabilities, but also to every user of your website. To make your site fully accessible you need to have that in mind right from the beginning. Accessibility is not an afterthought you can apply retrospectively to a site. Learn how screen readers and assistive technologies work and try not to do anything that will exclude these users from being able to fully use your site. Most techniques are common sense and are easy to implement. If you feel you don’t know enough about accessibility then look into it and put it into practice in your next project.

Avoid using hacks

When I first started making websites with CSS I found that I had issues with getting a design to work across all browsers. Next I learnt that I could use CSS hacks as a way to selectively overwrite the CSS rules to fix the differences, so I started using hacks every time I came across an inconsistency. This is a bad habit it’s all to easy to fall into. The main thing you need to do to avoid this is to understand firstly that there are default styles in force in every browser, and these default styles vary between each browser. To combat these differences we need to reset the default styles before we apply our own stylesheets.

To that end we can use a special stylesheet such as Tantek Çelik’s undohtml.CSS that resets the majority of the elements that have differences between each browser. Before you apply a CSS hack ask yourself “Am I fixing a known bug with this hack?” If you’re not then maybe you’re doing something wrong.

When applying hacks for IE bear in mind that IE7.0 could be released and fix some issues with standards support but still be susceptible to hacks designed for IE 6.0. Therefore the best bet is to use conditional comments. This proprietary feature in IE allows you to apply overriding styles only to that version of IE. In this way you can apply hacks to IE, safe in the knowledge that IE7.0 won’t fail due to incorrectly falling for a hack targeting at IE6.0 though whether it will need hacks of it’s own remains to be seen!

Don’t use inline styles

Another bad habit is to use in-line styles to add styling as you code. This nasty habit is pure laziness, inline styles have the highest specificity of all (1,0,0,1) so using inline styles will dominate any styling you write for the same element in an external stylesheet. In addition the whole reason we use CSS is separation of presentation from mark-up so inline styles make no sense.

Make your site flexible for different text sizes (aka Bulletproof)

If you are using XHTML and CSS properly then you should be able to build a site that doesn’t break if you resize the text. For example using Doug Bowmans’s sliding doors technique can help where you need to use background images in elements that will resize as the text-size changes. A great resource for making your site unbreakable is Dan Cederholm’s new book BulletProof web design

Use Javascript unobtrusively

Javascript as a client-side scripting language cannot be relied upon to be available on every user-agent, for example all browsers have an option to turn off Javascript. Because of this Javascript should only be used to enhance existing functionality and not break the whole site if Javascript is off. Avoid in-line events such as onclick, onfocus etc. Instead learn how to register event handlers in external scripts and make use of the DOM so that the behaviour layer is separated from the mark-up.

Ask for help

When you come across something you don’t understand, try and spend the time to fully grasp it. If you use Google and find a resource that has the answer to your problem don’t simply cut and paste the solution, read the article and find-out why it fixes your issue and you will have a useful bit of knowledge for the future.

Don’t be afraid to ask for help from your peers (work colleagues, friends or community resources such as the sitepoint forums) when you need to. This can be a two way process, you will learn from others and others will learn from you.

Challenge yourself

If all you ever do is fixed-width designs then try a different approach with your next project. The more ways you experiment with layouts, the more you will learn. Try not to design a site with how you are going to execute it in mind, try experimenting with a difficult design to put your CSS skills to the test.

Get to events/courses

Where possible get out to any web-standards conferences/events or workshops you can. Not only is this a great way to learn, you also get to meet other web developers and designers where you can make friends/contacts and swap ideas. Find out if your company has a training budget and see what courses you can get yourself on. It’s a great way to take your skills to the next level.

Resources

By no means should this be considered to be an exhaustive list but these are certainly good starting points for becoming a better standardista.

Mark-up/XHTML

• Tantek Çelik
• Molly E.Holzschlag

CSS and general Web Standards

• Doug Bowman – StopDesign
• Dan Cederholm – Simplebits
• Dave Shea – Mezzoblue
• Roger Johansson – 456 Berea Street
• Andy Clarke – And all that Malarkey
• Andy Budd

Accessibility

• Joe Clark
• Derek Featherstone
• Accessify.com – Ian Lloyd
• Juicy Studio – Gez Lemon
• Splintered – Patrick Lauke

Javascript

• DOM Scripting Task Force
• Jeremy Keith
• DOM scripting
• Stuart Langridge – Kryogenix.org
• Unobtrusive Javascript
• Quirksmode – Peter-Paul Koch

Browser Bugs / CSS Hacks

• Quirksmode – Peter-Paul Koch
• Dithered.com – CSS Filters
• centricle.com – CSS Filters
• Position is everything
• Box model hack

Events and training

• SXSW 2006
• @media 2005
• @media Master Classes
• Carson Workshops
• Clear:left training

Translations:

• Chinese – Zeal
• Summary in Spanish – Ismael Celis

4-5 months later and thanks to the whole webdev team pulling together we are beginning to turn the corner into a new era of cleaner, standards based code across the board

So how has this change come about? Well all of us that were already standards aware through our own noodling have spread the word; we have advocated xhtml 1.0 transitional to be the recommended minimum doctype from now on. Common included code was converted to validate as XHTML strict, so that we could now write sites as XHTML rather than HTML 4. Using inline styles was deemed bad practice – except for occasional circumstances like, “you are here” style overrides. In addition javascript ahould implemented in an unobtrusive manner, so that if a user has javascript turned off it won’t be detrimental to their experience of the site.

We also attempt to keep CSS hacks to an absolute minimum. Should laziness creep in it’s tempting to fix rendering differences between browsers with hacks straight away without checking for other reasons why these differences manifest themselves. Should IE 7 fix some of the known bugs but remain susceptible to some of the IE targetted CSS hacks then alot of pages will end-up adrift.

The next stage in the journey is to ensure that all server-side code outputs standards based code, otherwise it will be shame when all the hard work is ruined by a badly written server-side app; a common problem with Content Management Systems.

Overall these changes have come easier than I expected and I am happy to be able to code to my own standards.

1. You will learn so much more about webdesign and how pages go together. If you use a software application it is likely that you will know less about the code that the software is automatically generating for you.
2. Pages can be alot neater when you write the code yourself
3. It goes hand in hand with writing to current web standards as you are reponsible for the quality of your own mark-up
4. There is definitely a greater sense of satisfaction from creating pages without the aid of a design tool.

I would recommend anyone who is currently starting to get into webstandards to try using a text editor to put together pages, you never know you might find you like it!

Personally I recommend checking out Crimson editor. It features all common languages and features syntax highlighting.