While I won’t summarize all the things that the session speakers said (there are some links towards the end for that), here are some key things I took away from each presenter:

Open Data — Keynote Presentation from Jeremy Keith

This guy is usually quite funny, but this time he decided to read something he had written. I thought this was going to be a long and dry session, but instead it was very interesting, looking at the importance of

• Open data for accessible information (to everyone) and for digital preservation
• Standards for format longevity and innovation (bred by constraints)

He was approaching accessibility from the perspective of accessible data for everyone.

Assistive Technologies and AJAX by Steve Faulkner

Steve Faulkner is a noted accessibility expert and has lots of detailed information about accessibility on his blog (and in particular, some decent research on how screen readers work in different scenarios). His examples mainly came from Twitter, the micro-blogging tool.

There were some interesting examples of how WAI ARIA live regions would help make some simple features accessible, such as the text countdown that shows how many characters you have left to type, common on many sites where you fill in text areas.

(One of his points about the problem of using the abbr element’s title attribute to put in an ISO 8601 date time format eventually led to a public argument during the final panel session between Mike Davies and Jeremy Keith!)

Fencing in the Habitat by Christian Heilmann

Christian Heilmann works for Yahoo but has long blogged about accessibility, JavaScript and more.

This talk was about how not to approach accessibility. He has already published his slides and notes for the talk, so the only thing I will add here are my main take-away points:

• There’s no need to scare people into doing accessibility anymore
• It’s generally easy (despite a lot of misconceptions) and helps so many people. He described the immense joy some elderly people had when they were given a wii without any knowledge how to use it. Yet, very quickly they were having immense fun playing on it! Accessibility is more than guidelines; it is also about usability.

Rich Media and Web Applications for People with Learning Disabilities by Antonia Hyde

This talk was really interesting about how a group that is often left behind in accessibility implementations — people with learning disabilities — are affected by the web.

A number of instructive videos showed how some people can struggle with common features on sites.

She ran out of time but put up her slides on her blog.

User Generated Content by Jonathan Hassell

Jonathan Hassell is the head of Audience Experience and Usability for BBC Future Media & Technology. He also leads the BBC Usability & Accessibility team so had quite a lot of interesting things to say.

User generated content is of course a major issue in modern web sites when it comes to concerns like standards and accessibility.

One of the strategies Hassell mentioned was to use a moderator approach, accepting it is really hard to get end users to know about how to create accessible content. This way, a moderator adds accessibility and other things once the content has been created.

This is quite an expensive way to do thing, he accepted and sometimes will not be possible.

The other problem is that as more content moves away from basic text-based formats that is the web, assistive technologies will struggle even more to provide accessible alternatives. While not impossible, the implications include the following:

• Those formats require accessibility be built in, or have alternatives
• Content producers will become increasingly responsible for accessible content

The other point he stressed, like many others, is that accessibility is a misleading word; it is really an issue of usability.

As content becomes more multi-media the additional challenge he finds is how to make such multi media accessible in innovative ways. One example was using 3D and stereo sound in a Flash-based children’s game where they had to push a train carriage from the left part of the screen to the right hand side. By using 3D sound and stereo, audio feedback to a child who is blind or has poor eyesight, would still allow them to experience more of the game than usual. Another game showed sign language being used.

Another interesting point he made was regarding JavaScript: As a number of people have noted for a long time, there is a common misconception that JavaScript is an accessibility no-no. Hassell noted that it helped make the new BBC home page more accessible to screen readers, rather than less.

A Case Study: Building a Social Network for Disabled Users by Stephen Eisden

This talk was about the user testing, accessibility audits and technology decisions that come with building a social network for disabled users called Disability Information Portal (DIP). After evaluating a few different ways to do this, they settled on WordPress as the basis of their network, currently in pilot stage, http://www.dip-online.org/.

Eisden also noted that an accessible site was generally a more usable site, too.

Tools & Technologies to Watch or to Avoid by Ian Forrester

Ian Forrester runs BBC’s Backstage, a web site for designers and developers.

This promised to be an excellent session, but for some reason they only gave him about 20 minutes and he had some 80 slides to go through! So he had to cut really short which was disappointing. I had the opportunity to talk to him a bit more after the sessions were over, and that was really interesting. He has a good interest in XSLT too

Some of the points he did manage to get across were how some Web 2.0 sites made it hard enough for normal users to do things, let alone people with additional needs. Examples included hard to understand user licenses and terms & conditions; Flash videos and captioning; using various sites to import contacts or export data, etc.

Accessibility 2.0 Panel Discussion chaired by Julie Howell

This panel was an interesting enough discussion, chaired by one of the most prominent people in the accessibility circles. Nothing to really add here that is not captured in the notes by others listed below.

Slides and notes from each session

AbilityNet, who hosted the conference will be putting up videos and transcripts of each session shortly.

Jeremy Keith, one of the speakers, and well known for his work on DOM Scripting (I think he coined that term?) was taking notes during the session and posted them as follows:

1. Open Data by Jeremy Keith.
2. Making twitter tweet by Steve Faulkner.
3. Fencing in the habit by Christian Heilmann.
4. Rich Media and Web applications for people with learning disabilities by Antonia Hyde.
5. User-generated Content by Jonathan Hassell.
6. A case study: Building a social network for disabled users by Stephen Eisden.
7. Tools and Technologies to Watch and Avoid by Ian Forrester.
8. Accessibility 2.0 panel discussion with Mike Davies, Kath Moonan, Bim Egan, Jonathan Hassell, Antonia Hyde and Panayiotis Zaphiris, moderated by Julie Howell.

Christian Heilmann also did some live-blogging and posted his notes up on the Yahoo Developer Network. He also includes a number of additional links to speakers, and other live-bloggers.

Summarising the whole day

A common theme running through the day was that web accessibility is not just for disabled people; it is about usability and ensuring as wide an audience as possible can access the content.

Jeremy Keith also had a useful summary:

All in all, it was a great day of talks with some recurring points:

• Accessibility is really a user-experience issue.
• Guidelines for authoring tools are now more relevant than guidelines for content.
• Forget about blindly following rules: nothing beats real testing with real users.

– Jeremy Keith, Open Data and Accessibility, April 26, 2008

The shortest summary I could probably give is this:

Accessibility on the web not only benefits people who are considered disabled, but a much wider, often aging, population.

Some people still claim that people with such needs don’t use the web (see further below). Watching people use the web using assitive technology may however, change perceptions.

What does accessibility mean?

A decent article by Jonathan Snook asked What does accessibility mean and summarised his thoughts as follows:

As a web professional, I try to build sites that reach the largest audience possible. Every design decision has a consequence and those consequences have to be weighed against the goals of the site. Accessibility is just usability after all. We’re not designing and building these sites for ourselves, we’re doing it for other people, too. While it may seem easier to just ignore whole segments of the population, for the vast majority of us building web sites, we already have the tools and knowledge out there.

… So, let me try and boil this down into some bullet points:

• Accessibility is usability. We’re all just trying to make things that people can use.
• Basic accessibility isn’t hard. We should be doing stuff like alt-text, making sure form fields are labelled, etc.
• Don’t expect perfection. It’s possible to get it wrong, especially as more layers of interactivity is added. It’s not a bad thing. Just learn from it.
• Just because we can’t, doesn’t mean we shouldn’t. By this I mean, just because we might not be able to cater to everybody doesn’t mean we shouldn’t do it at all.

– Jonathan Snook, What does accessibility mean, snook.ca, November 27, 2007

He noted (as did some of the commenters on his blog) that many aspects of accessibility can be achieved simply through better markup, or more meaningful, semantic markup.

While some additional technology layers such as JavaScript and AJAX can complicate matters, it doesn’t always have to.

Sometimes effort is needed. Other times, these technologies can actually help, as accessibility isn’t just about blind people, and isn’t just about when JavaScript is turned off, though these scenarios can be important in themselves.

As an aside, it is interesting that estimates of how many people have JavaScript turned off vary from around 5 to 8% of users, depending who you read. That is a large percentage, often larger than users of browsers such as Safari, depending on your site.

So, from some perspectives accessibility can also mean different technology configurations — thinking of Google as a “blind” user may also offer a different perspective!

“Blind people don’t use the web”

Snook’s article linked to Jeremy Keith’s short post on the reaction of some people in response to the lawsuit being brought against Target for preventing blind people from shopping on it.

The reactions were along the lines of “blind people don’t use the internet”, and other such arguments that the web standards movement addressed years ago (but, as with many issues, it still keeps coming up).

A self-fulfilling argument

Interestingly, such arguments as those above are self-defeating, or a self-fulfilling prophecy:

1. Argue that people with accessibility needs don’t use the web;
2. Therefore create web sites which pose a barrier for such people;
3. Therefore argue that such people don’t use the internet.

And so, you can easily get stuck in a recursive loop without any exit condition.

Assistive technology can help many people, not just those considered disabled

In 2003, Microsoft commissioned Forrester Research to conduct a study on accessible computer technology and found that,

57 percent of current working-age computer users may benefit from accessible technology because of mild to severe vision, hearing, dexterity, speech and cognitive difficulties and impairments. As the U.S. population continues to age, the number of people who experience these impairments will increase, and more people will likely turn to accessible technology to mitigate the effects of their changing physical abilities.

– New Research Study Shows 57 Percent of Adult Computer Users Can Benefit From Accessible Technology, Microsoft, February 2, 2004 (Emphasis added)

Now, that is quite some time back and limited to the US working population, but shows that accessibility isn’t just people having official disabilities, but includes a much wider population.

Further, considering changing abilities as people age, and that in many Western societies in particular an aging population is likely to increase, then these things have greater significance for people creating software, including web sites.

Seeing people use assitive technologies on the web

In addition, actually seeing people who do have special needs attempt to use the internet is interesting.

Roger Johansson posted links to videos of people using assistive technology, and not just screen readers.

Web Accessibility In Mind, or WebAIM, also posted some videos showing how simple markup choices can affect accessibility of HTML data tables for screen reader users.

I have also been to the Royal National Institute for the Blind in London to talk to and watch blind people using retail e-commerce web sites. It was a good experience. At one point for example, a particular site they visited had an unannounced pop-up, which was incredibly disorienting for the user (who was a reasonably seasoned JAWS screen reader user). It was good to see that when a window popped up from an action, such as clicking a button or link worked without problems (because it was the result of a user action, not an unexpected automatic action as part of a page load). So, not all pop ups are bad

At that same session (this was back in 2005), they used a site we had creating using modern web standards, headings, (some of which were moved off screen, as they were not needed for the visual design, but were important as part of the document), lists for menu items, tables only for tabular data, and so forth. We didn’t mention any of this to the screen reader users, but they commented that they had no problems on such a page, and the use of headings was really handy.

More information

The point is that simple and appropriate markup choices go a long way to provide accessible content and it may help more people than you realise.

The W3C’s web accessibility initiative provides guidelines for further accessibility and there are of course other techniques that can help when using more advanced techniques, such as DOM manipulation via JavaScript, or AJAX.

Here are some examples and articles for further reading:

• Web Accessibility Initiative (WAI) from the W3C
• Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap), part of the WAI
• AJAX Accessibility Overview, by Becky Gibson, Web accessibility architect, IBM April 2006
• ARIA: Accessible Rich Internet Applications/Relationship to HTML FAQ, a decent FAQ from Mozilla
• ARIA Proposal for HTML 5
• Improving Ajax applications for JAWS users by Gez Lemon, 19th January, 2007 (this article notes an undocumented behaviour in JAWS that can be used simply and quickly to notify screen reader users of updates to part of the page).

Why bother?

Visual designs often require hiding text in such a way that screen readers will still read the text and thus provide extra context for the screen reader user.

For example, a visual design may make the main navigation section of the page obvious and so a heading to announce it may be unnecessary or undesirable.

However, from the perspective of good document structure/semantics and accessibility, it would be good to have the heading in there.

Screen reader users, for example, often scan a page through having a list of headings being read out to them.

The problem of display:none in CSS?

display:none in CSS would seem ideal (plus some additional rules in an aural stylesheet, perhaps).

Unfortunately, screen readers are inconsistent in the way they handle display:none.

In addition, most do not yet support the aural stylesheet sufficiently.

Positioning text off the screen is more reliable

For years, I have been using an “off-top” technique whereby content can be moved off the top of the screen, in such a way that it will still be read out by screen readers. Here is an example:

.css-label {
    height:1px;
    left:0px;
    overflow:hidden;
    position:absolute;
    top:-500em;
    width:1px;
}

A simple example of using the above may be to provide a header to a section such as the navigation:

<h2 class="css-label">Navigation</h2>

Some use use an “off-left” approach instead, though it seems to cause the odd problems with earlier versions of Opera and Safari (any one using those anymore?)

That being said, a comment left on Gez Lemon’s post about display:none issues answers my question of whether off-top is better or not than off-left saying there may be some issues with off-top. I’ll need to look into that further, but either of those are certainly better than using display:none.

More information

For further reading, see the following:

• Hiding Content from View, AbilityNet, November 2007
• Screen Readers and display: none, Gez Lemon, Juicy Studio, 12 October, 2007

Will search engines see this as keyword stuffing?

A comment left on Gez Lemon’s post asked what would be the impact on search engine listing?

Comments are closed on that post, so I will try to answer it here, as it is something I have been wondering for a long time.

The concern from an SEO point of view is that search engines may think you are tricking them even though this is a legitimate techniques for a legitimate purpose. However, some people could use these techniques for keyword stuffing, thus putting this useful technique in jeopardy and making it harder to provide sufficient context to assistive technologies.

Search engines would likely have a hard time detecting this in an automated manner

But for search engines to detect this they would at least need to parse all the CSS. Then, they would have to looking for all the different permutation of these rules and be 100% sure this is being done for keyword stuffing and not for some other legitimate reason.

Sounds tricky (and easy to circumvent — e.g. by using JavaScript to set these styles, as it is only being hidden from visual user agents).

Or, search engines would need to implement an entire DOM and calculate where on a screen all the text would go. Some major web browsers struggle to do this properly, so search engines aren’t likely to do it too well either, I would think.

But they may use manual checks for better results; that would be good for legitimate use of this technique

However, while automation and throwing lots of servers at a problem may seem problematic (for now!), these things require human, subjective, interpretation. So why not have people check sites manually?

Google, for example, does have a little army of people to manually verify sites are not using unfair tricks. So I guess if they are concerned about this particular technique, they might be able to get software to go a certain distance and then flag up suspicious cases to be manually checked. Legitimate sites should then be okay.

More information

But don’t take this as advice! Search engines often change the way they work! So check out this article from SEOMoz, a prominent SEO web site: A Comprehensive Guide to Hidden Text & Search Engines (10 July, 2007).

The article looks at how each tool (or plugin) provides various options for tagging PDFs so that the output will be more accessible. The test document is just a simple one, and even there differences can be seen!

Rich, AJAX-based sites are taking off. When done well, they provide rich user experiences. Unfortunately, it feels as though accessibility is being left behind. This is a sad irony, given accessibility was important in galvanizing so much support for web standards.

Screen readers struggle with dynamic pages, tag soup is still prevalent, and some browsers still don’t implement standards properly.

In addition, HTML (as it was defined almost a decade ago!), CSS and JavaScript were not built with today’s web applications in mind. Some people therefore suggest other technologies such as Flash, which has come a long way, and now includes various accessibility features, too.

But there has long been a move to update the HTML specifications. It has been slow moving but recent months have seen a number of interesting things arise.

Proposal for HTML 5 is promising

The W3C has long had XHTML 2 specification drafts, while the Web Hypertext Application Technology Working Group (WHAT WG) has been suggesting HTML 5 to deal with rich internet applications that are becoming the norm today.

In fact, the W3C voted to adopt HTML 5 as proposed by Apple, Mozilla and Opera.

Not only that, but the W3C has agreed to the proposal of having Ian Hickson of Google (and spokesperson of the WHAT WG) and David Hyatt from Apple /Safari to be the initial HTML 5 specification editors.

XHTML 2 goes down the route of strict XML-based syntax and validation (markup errors result in errors on the browser, not browsers trying to still show the page). This is nice ideally, and could allow a clean start away from the current HTML mess. However, many have felt it will be difficult to adopt and not everyone will be able to ensure well-formed markup. The HTML 5 approach has been to be backward compatible (though it now also entertains an XML-version of the markup, i.e. XHTML 5).

The other concern is for older browsers that may have to render newer version(s) of HTML. HTML 5 tries to be somewhat backward compatible, so potentially an older browser will be able to render the new pages even if it is not as visually as appealing. (XHTML 2 seems to be like this too, given older browsers will just try to treat it as HTML and anything not understood would just be ignored.)

There are certainly lots of debates going on out there about HTML 5 versus XHTML 2 and various details of each specification, but the bigger picture is the potential for improved accessibility, productivity, usability, richer applications, etc.

Better markup is the foundation

The potential comes from the richer markup that is proposed.

HTML 5, for example, introduces a whole host of new elements, from structural elements such as header, footer, nav, and section. New multimedia elements include video and audio. And new form elements/types include date, email, and datagrid. There is even a proposed event-source to catch server side events. (Read the really useful HTML 5 differences from HTML 4 article by Anne van Kesteren, from Opera.)

Key benefits for users would include

• Consistency across web sites
• Accessibility

Key benefits for businesses, individuals and organisations developing web applications include

• Increased productivity
• Legal compliance (where accessibility is a legal requirement)

The consistency benefit is interesting: while some may fear that web sites will end up looking the same, some fundamental functional features are important for consistency across sites, such as form controls.

Why? We expect desktop applications to behave in the similar ways (e.g. the menu bar along the top of OSX or the top of each application in Windows, etc). In the same way some fundamental consistency of interaction on the web will be important too, for example, how dates are picked, how email addresses are validated, how data grids work, etc. This will help new users to a site quickly adapt, rather than having to learn a subtly new way of doing something similar to elsewhere.

This will be good for accessibility because assistive technology can more easily work out what a header is, or what a nav is. It will therefore be far easier to present navigation and usage options to the users of such software. Even browsers will be able to build more accessibility features right into the browser. All this without sacrificing design and development flexibility.

HTML 5′s proposals for numerous new input types and other semantic markup elements (e.g. calendar related inputs, better data grids, header/footer elements, etc) is really key, IMO.

Anne Van Kersteren provides some useful examples of form controls:

Nowadays web developers use nifty scripts to perform form validation on the client side. Soon you’ll be able to simply write the following:

<form>
 <p><label>Name: <input name=name required></label></p>
 <p><label>E-mail: <input name=email type=email required></label></p>

 <p><label>URL: <input name=url type=url></label></p>
 <p><label>Comment: <textarea name=comment required></textarea></p>

 <p><input type=submit value=React!></p>
</form>

– Anne Van Kersteren, Improve your forms using HTML5!, Dev.Opera, 13 December, 2006

Examples of why this is beneficial:

• Developers get to focus on developing sites and apps, rather than common controls (which would all be different between different sites).
• Users get familiar widgets (which are probably similar to the operating system, too, making such sites quicker to learn and use).
• Assistive technology will help their users use the site more easily. Assistive technology vendors will have richer elements to support but typically only do it once (per element per browser implementation!).
• Improved quality as not only would HTML bloat may be reduced, even more important might be the reduction in JavaScript, hence the reduction of buggy sites, memory leaks, performance issues, etc.

This would translate into more productive businesses and organisations. The content is also potentially easier and better for indexing for search engine.

All round win-win, in my view!

Of course this is overly optimistic. Some companies already provide these pre-packaged controls with today’s HTML so some perceived efficiency/productivity may not be as high as it sounds (ignoring the extra work that might be needed to make such controls accessible, search engine friendly, etc).

With something like HTML 5 being adopted and used widely, hopefully this means people can spend more time innovating, and less time dealing with browser problems!

When will this happen!

So lets come back down to earth again!!

Its all well and good to talk about the potential of something like HTML 5, but will it ever happen? Almost everyone will agree that this will all take a long time to adopt.

Browsers need to add new code. (Will those browser releases even be in remotely the same time frame? Does this ultimately depend on Microsoft’s Internet Explorer supporting it?)

And getting assistive technologies such as screen readers to support a new specification may take even longer.

If these new specifications are desirable, what will provide the impetus for tons of web developers to want to learn something new, for businesses to spend resources in up-skilling and moving to these?

Search engines.

What? Yes, search engines. If search engines were to buy into HTML 5 and say they will index the new tags, then businesses may have compelling enough reason to move into that direction. Better indexing may mean more accurate results. (Ranking of course is different to indexing which is a separate issue!)

Of course some people may now just have more HTML elements to abuse and stuff with inappropriate content. I don’t imagine any time soon search engines saying some elements will have higher precedence for ranking purposes, and instead continue to focus on social factors, how popular the site is, etc. But indexing is still important: let search engines find content, but let them also understand what is there so if the page does rank, then the right information can be shown, which helps users decide if they want to follow the link.

There are signs that things are moving in the right direction: Google as well as Apple, Mozilla and Opera are putting weight behind HTML 5. Ian Hickson has already started providing some initial analysis for HTML 5 parser implementors, for example.

But there is one big player missing in the above that can also be make or break. Microsoft. Whatever we feel about the company (most web developers that follow web standards despise IE!) their browser install base is so wide it cannot be ignored.

What about Microsoft and Internet Explorer!

This may feel odd to think about, but there’s another potential winner in HTML 5 adoption: Internet Explorer!

Microsoft’s IE is generally regarded as the least capable of modern browsers (e.g. buggy/limited CSS support, limited W3C DOM support, etc). With something like HTML 5, it is a clean slate for Microsoft.

If Microsoft want to rebuild their reputation with web developers, they should also buy into HTML 5, but this time truly support the standards, rather than go half way, win the wars and then act as most monopolies would!

There are people at Microsoft, such as Chris Wilson who leads the IE development, to whom standards is definitely important (their need to support older sites full of tag soup — partly their own doing — has slowed them down from making fixes and supporting even more modern standards) so it may be more realistic this time than in the past.

Where next?

There are definitely some odd technical decisions, outstanding concerns, and debates in terms of where XHTML 2 and HTML 5 are headed. With the W3C’s adoption of HTML 5, XHTML 2 seems dead for now, but it seemed to have a few good things which don’t seem to be there in HTML 5. HTML 5 also has a few seemingly inconsistent decisions. And so on.

So what can be done? A few things, I guess. E.g.:

• Read the HTML 5 drafts
• Join the HTML working group at the W3C if you have time!
• Get involved with the WHAT WG
• Start pressuring search engines and browser vendors! WebStandards.org, is this a campaign for you guys??

Sometimes, all I have done is just the following:

• Switch from Arial to Verdana
• Put some line-height on the body (a good amount, such as 1.5, even 1.8 or more)
• Where I can, provide good use of margins and paddings around major chunks of content

Nothing more. And those times I have not thought much of it, but then I get a few comments like “Wow! It looks SO much better! What did you do!”

Conclusion? CSS line-height and white space are your friends! Not only do they improve usability, but simple accessibility, too, while being more aesthetically pleasing. Use them!

Side notes:

• Other times, I may have also needed to improve/clean the markup too.
• Public links not available at the moment, sorry — will see if I can get some screenshots.
• If you require a serif font, try switching from the narrow Times New Roman to something wider like Georgia. Wider fonts (for content) such as Verdana and Georgia improve screen reading, as the brain can more easily make out the shapes etc. For that reason, also avoid all caps. Titles are a different case, and things like Times New Roman (especially italicized) can look quite nice. My personal thought of Arial: I don’t like it!

A clarification before continuing: we are talking about professional web development. Not necessarily people who need to enter content through a CMS, for example. (Good quality WYSIWYG editors are important for such users, however, which will be the subject of another post!)

For many people, a nice WYSIWYG editor seems like a good idea:

• It offers convenience when creating markup for web pages
• The ability to either drag various controls onto some kind of canvas, or quickly hit a ‘b’ button or choose a font, seems efficient and quick

However, what seems efficient and quick may actually slow down development and maintenance because of things like:

• Poor quality output markup and code
• Inaccessible content
• Excessive output (code bloat)
• Potential cross-browser compatibility issues

The main reasons, I feel, are the following, in no particular order:

• WYSIWYG editors may encourage bad practice
• Developers may lose full control of the output
• Competing requirements for web sites often not achieved through WYSIWYG; WYSIWYG is the wrong paradigm
• A number of WYSIWYG editors rely on Internet Explorer!

What you see may not be what you need.

WYSIWYG editors may encourage bad practice

(X)HTML markup is about the document structure, not how it looks (although this is of course immensely important overall).

Using a WYSIWYG editor might encourage bad practice, if the developer is not already well-versed in web development.

Why your choice of markup is important

Consider a simple example of rendering a list of menu options, running across a page, each option separated by a vertical bar. People often use a div or a paragraph element and separate links with a space and ‘|’ rather than semantically marking it up as a list of menu options (a ‘ul’ or ‘ol’), followed by CSS to float each ‘li’ next to each other and give a left or right border to all but one the first or last item, for example.

If a web developer knows what they are doing, they may be able to use the WYSIWYG editor to quickly write out a bulleted or numbered list in this way. More often than not, it seems, people preferring WYSIWYG editors are those that will not do this. They may be middle tier or desktop GUI developers doing web development, or preferring tools that hopefully hides the details of web development for the perception of efficient development.

As WYSIWYG may be natural for the more mature desktop GUI environment, I can understand such developers expecting to use similar tools for web pages. However, I don’t think that necessarily applies to web pages.

For the web, while the look of a site/page is incredibly important, the different technologies used on a web page serve different purposes. (X)HTML is about document structure; CSS is used for the look, for example.

Who cares about/benefits from semantics?

A semantically marked page makes it more accessible to a wider audience.

One of the powerful things about the web is the ability to interpret the document (i.e. the (X)HTML) in many ways, by many tools (web browsers, search engines, screen readers, etc).

Accessibility is a legal requirement in many countries. Much can be achieved simply by using better markup so that assistive technology can understand and represent the content to their user as accurately as possible.

It is also, to a lesser extent, good for search engines to index your content — think of Google as a blind user! (But note, indexing is not the same as ranking — will clarify this in a later post!)

WYSIWYG editors often provide inappropriate buttons and shortcuts

A WYSIWYG editor doesn’t encourage thinking about such semantics of the markup; if it looks right then that is enough.

Many WYSIWYG editors offer the classic word processor type of icons, ‘b‘, ‘i‘, even the confusing and often unnecessary ‘u‘. These are all presentational even though they are given prominence.

Some WYSIWYG editors do use the more semantically useful strong instead of ‘b’. But, for ‘i’, while most will go for em, cite is often another use for italics. (There are also times when neither em or cite truly represent the purely presentational italics required in some types of text. Toolbars however, rarely offer all the options, or they get cluttered very quickly!)

Developers may lose full control of the output

Some development tools have been notorious for making it difficult for developers to view the HTML source and make manual changes. Microsoft’s Front Page was probably the most well known! Even their Visual Studio 2002 and 2003 were very bad in this area (made it almost impossible to use an XHTML doc type if using the WYSIWYG editor), though Visual Studio 2005 is a lot better (but still not that great — another post will talk about this!)

By their nature, WYSIWIG tools will decide to mark up content in a certain way. Developers will therefore switch to the source view from time to time to correct or enhance things. Some tools (again, older Front Page and Visual Studio 2002, 2003 spring to mind, in particular!) actively change your own changes! I think, to be fair, this is less prevalent in editors today, but many are still using these older ones, so the problem does exist.

(To its credit, ASP.NET 2 comes with something called the CSS Control Adapter Toolkit, which allows you to change how something is rendered. IMO only, it feels messy and a roundabout way to do something that could have been marked up better in the first place. I can see where it could still be used, even for decent initial markup. It is unfortunately mis-named. These adapters should be used to create semantic markup, regardless of whether it is for CSS or not.)

Why do web developers need full control? To have the freedom to create what is needed, to meet the various web page requirements. Also, if using modern CSS-based layout techniques, knowing the nature of the output is important to create optimal code.

Competing requirements for web sites often not achieved through WYSIWYG; WYSIWYG is the wrong paradigm

Seemingly competing requirements of a web site may include the following:

• Cross-browser compatibility (without having to inefficiently code differently for each browser)
• Accessibility (a legal requirement in many countries)
• Search engine visibility (important for many, many businesses
• Fast downloading

The power of the World Wide Web is its ability to provide content to a variety of people, and technology.

Whether it is the web browser, or a search engine, or assistive technology, all these things will access your same content and try to interpret and represent it as best they can for their user. From a business perspective, richer and richer functionality is needed, yet the page always needs to load quickly, so reducing excessive markup bloat can be important.

It is therefore crucial that the underlying markup is sound and semantically accurate (within the current limitations of (X)HTML).

Providing this extra semantic markup doesn’t get in the way of nice visual designs. (Sometimes it can help reduce the code you need to achieve the same designs.)

The perception that WYSIWYG editors will be efficient falls down when thinking about all the time that will be needed subsequently to ‘fix’ it for SEO, accessibility, cross browser compatibility, etc.

When done up front, as part of the initial project, it is much cheaper (and, I find, often without any excessive overhead).

It is the importance of semantic markup, that makes WYSIWYG the wrong paradigm. It is not what you see that is important (from an editor and (X)HTML point of view), but how you mark your content up.

The above menu list example is worth pondering again. A web standards-aware developer, even if they use a WYSIWYG editor, will opt for a bulleted or ordered list. That on its own is not what you will see by default, if CSS is used to lay it out horizontally, as per above.

If a WYSIWYG editor attempts to provide CSS support too, that could help, and a number of editors are now providing sophisticated support for it (e.g. DreamWeaver and the next release of Visual Studio).

To help out, an editor could implement a standards-compliant CSS engine that can continuously update the WYSIWYG canvas as the developer edits it. This would make for an expensive product, potentially! Or, the editor would need to hook into an underlying browser, which leads to the next problem:

A number of WYSIWYG editors rely on Internet Explorer!

There used to be a time when web developers had to suffer developing for Netscape 4 as well as IE. Netscape in those days used to be full of problems. Now, it is mostly IE 6 and below in particular, that are the buggiest browsers when trying to use modern, established standards/recommendations to achieve all the competing requirements.

That being said, many modern web techniques can still be successfully used even with these browsers.

However, for those WYSIWYG editors that try to provide CSS support, using IE 6 or even IE7 as the underlying rendering engine is the wrong approach. You want to develop to standards, not specific browsers. Reasons:

• Of all the modern browsers, IE (6 and 7) have the most CSS and other rendering bugs
• Standards-based development should be tested against more standard compliant browsers first (e.g. Firefox and Opera)
• This encourages better coding practices
• Only then should the problems that mostly occur in IE be dealt with
• This works even when IE is the major browser for the site, because the pain of supporting multiple browsers diminishes significantly if developing according to standards, rather than browsers

Can WYSIWYG for web markup ever be good?

Where web developers know what they are doing, decent WYSIWYG tools could be used responsibly.

But, even if say marking up the simple menu example above as a bulleted list, then what you see may not be what you get if the editor doesn’t support CSS.

Where the editor does have CSS support, if the Internet Explorer 6 (or even 7) rendering engine is being used, then what you see may encourage inappropriate fixes or code that works in the WYSIWYG editor, but then breaks in other browsers, or even a future IE that fixes its numerous current problems!

One the one hand, I hope that future editors will be far better at these things. On the other hand, even if they improve can they improve enough?

Possible reasons why WYSIWYG may become useful:

• Editors should get better over time
• Many vendors are embracing modern techniques and standards
• Many tools are incorporating sophisticated CSS-based techniques and ideas

For example, DreamWeaver CS3 by default creates descendant selector chains when it generates CSS for you, which sounds very powerful. Visual Studio 2008 will try to encourage better CSS rules re-use. These and other tools offer a ton of CSS management capabilities as well as markup support, so that might be quite useful.

A number of editors also provide additional “widgets” out of the box. E.g. menu bars, animation and other visual features, etc. If, after evaluation, these are appropriate for your needs, produces appropriate markup, meets accessibility, search engine and other needs, then it would seem useful to use those widgets.

However, possible reasons why WYSIWYG may still be unnecessary or hamper development in the foreseeable future:

• Ultimately, it is still feels like the wrong paradigm. What you see may not be what you get and may certainly not be what you need
• Developers will still need to know the output they need if they are to address the multiple requirements typical of most web sites
• Writing the output by hand is ever so quick anyway, and not something to be scared of (we are talking about web professionals here, so intimate markup knowledge is assumed)

(HTML is quite limited in what elements you have at your disposal. While not everyone would know every single element and attribute, the common ones are easily remembered when done repeatedly, just like a programmer in say C will remember most capabilities, but occasionally require a reference manual for some more obscure stuff. And despite the limited web languages, as a post at 37signals notes, coding in those limited web languages is quite pleasant. I’d tend to agree. I know many programmers may see HTML/CSS/JavaScript as too low or not enough of a language, and I certainly like Object Oriented Programming, but I agree with that previous post when it comes to web interfaces!)

Will improved WYSIWYG editors help make the “wrong paradigm” issue go away, or diminish as a concern? Don’t know.

Regardless of the direction, knowing the underlying markup will remain important for a long time, I feel. Kind of like how even though SQL has been around for decades, as have tools that can generate SQL for you (e.g. by drawing lines between two tables, entering conditions in some sort of condition builder), serious DBAs prefer to code by hand. Or, although various tools can create C# or Java or other code for you, developers still need to know those languages.

Using open standards on the server side to output open standards on the client side

One thing I have done successfully with ASP.NET (including ASP.NET 2) is by-pass the whole ASP.NET controls mechanism, in effect, overriding the Render() method to transform XML data with some XSLT instead. XSLT is an open standard and offers full control over the output that needs to be created.

This helps to create a very clear separation between presentation logic (the code to process inputs/posts to the page, request services/data from the middle tier, etc) and output construction (i.e. creation of the markup/response to the client).

Although the way you write your presentation logic is dependent on your platform, the output construction is somewhat platform independent. (With object oriented languages like C# and PHP 5 on the server side, the design pattern for the presentation logic code is also highly reusable.)

I have been able to port the same pattern from classic ASP, to ASP with COM+, to ASP.NET and even to PHP with practically no changes to the XSLT (other than the use of the node-set feature or how the document() function might be used, which are typically minor changes).

Of course, this might be overkill for simple sites, or inappropriate for some situations, so will be the subject of a subsequent post.