If you have an editable box with TinyMCE, and that box will appear on the website if it contains content, sometimes you can get a ‘blank’ box. When a user deletes content from the box, they might not delete everything in the box, leaving some blank HTML tags.

For example, if there was a list of links, and you use the mouse to select the list, and press delete, it can leave either <ul></ul>, or <ul><li></li></ul> depending on the browser.

In our CMS, when that went through to the front-end page the HTML content meant the box was displayed, but without visible content.

I messed around with some of the TinyMCE API events, ruling out onSaveContent and onSubmit.

The key event was onPostProcess, which allows you to run a script on the content before it is submitted.

Combine that with a little script from Stackoverflow to strip HTML from text with JavaScript, and you get:

tinyMCE.init({
   ... // other settings here
    setup : function(ed) {
    // If there is no text content, return nothing.
    //   NB: Image-only content would get swallowed.
      ed.onPostProcess.add(function(ed, o) {
            var text = "";
            var tmp = document.createElement("DIV");

            tmp.innerHTML = o.content;
            //console.debug("inner html=" + tmp.innerHTML);

            if (tmp.innerHTML) {
               text = tmp.textContent||tmp.innerText||"";
               text = text.replace(/\n/gi, "");
               text = text.replace(/\s/g, "");
               text = text.replace(/\t/g, "");
               //console.debug("if content, text=" + text);
            } else {
                text = "";
                //console.debug("else no content, and typeof =" + typeof(text));
            }
            if (text == "") {
                o.content = text;
                //console.debug("content set, possibly, get content = " + o.content);
            }

      });
   } // add comma here if there's another thing in the list
});

The only weakness I know of in that, is that something containing only an image but no text would return a blank box. I left the console logging in (but commented) if you’d like to see what happens though Firebug.

Free free to use this or to feedback any improvements below.

SharePoint 2007 Landscape

After a quick introduction from Nick Wilson (Managing Director of HiSoftware EMEA), Thomas Logan (HiSoftware VP of Product Management) took a look at the current situation with SharePoint 2007 (SP 2007).

The first point was stating the obvious, but just so everyone knows, Microsoft has been one of the more honest CMS vendors saying SharePoint is Not accessible to a particular standard. Well, to any standard really!

HiSoftware’s Accessibility Kit for SharePoint (AKS) is intended to repair issues with out of the box SharePoint, and also included an accessible Rich Text Editor (RTE).

Thomas demonstrated some of the improvements that the AKS could help with:

• SharePoint 2007 doesn’t allow text resizing (in Internet Explorer). When using AKS and the text can be increased, and it does actually change. However, from where I was sitting it increased by about 30%!? I know IE has some bugs with EMs, but the size really didn’t change very much.
• Thomas went on to show a form where you’re able to add explicit labels to inputs (not possible in SP 2007 in some situations).
• Quick demo of the Accessible RTE (aRTE), navigating in the editor with keyboard, apparently this uses ARIA concepts.

WCAG 2 & ARIA

Thomas called the Web Content Accessibility Guidelines (WCAG) version 2 the new global standard (although really it’s guidelines, not a standard).

Thomas notes:

• There is now a heavier reliance on manual testing (despite the W3C’s aim that WCAG 2 be more precisely testable with automated testing.)
• There is a different and more complicated lexicon on information design techniques.
• Frequently overlapping requirements (e.g. forms have things that need to be perceivable/operable etc.)

The presentation showed a spider diagram of principles / guidelines / success criteria / techniques, commenting on how it is a bit of a web of things you need to know. I quite agree with the point that when testing or developing, the sufficient techniques would be better listed by functionality type, however, that isn’t the intent of the core guidelines.

Web accessibility timeline

Thomas showed a diagram of (legally) important milestones in accessibility:

1. WCAG 1 (1999)
2. Section 508 (2000)
3. JIS x8341-1 + other standards
4. Section 508 refresh (2008)
5. WCAG 2 (2008)
6. New Zealand adopts WCAG 2 and EU recommends WCAG 2

NB: HiSoftware have a CD with lots of white papers on laws, regulations, standards and settlement agreements, get in touch with them for a copy.

Apparently a Judge in New York used WCAG 2 (double-A) as the standard that should be met, rather than section 508. I’m not sure if this is a reasonable comparison? If the company in question are a private company then the ADA legislation (using WCAG 2 as a benchmark) would be applicable rather than Section 508. It’s funny how the procurement guidelines (Section 508) are more widely known than the more general law. (Struan Robertson points out the ambiguity of the ADA.)

The next slide was a diagram with national standards as a circle inside the larger WCAG 2. I suspect it would be more accurate to show standards such as BSI 8878 stacked on top of WCAG 2, building on the guidelines.

Testing best practices

Thomas provided some good advice on testing a SharePoint site from HiSoftware’s point of view. (However, I wish people wouldn’t refer to Meeting double-A regulation!)

• Start with most common issues, page templates and style sheets. (Thomas talked about the blessed way of web development being the CSS way.)
• Focus on key scenarios/pages.
• Group related manual test work (i.e. by function rather than by guideline/principle)
• Document work to demonstrate progress.
• Use a representative page from each template.

Something that came across more from the words than the presentation was that it’s an uphill battle. Comments like I’d always like to be 100% complaint, but there’s usually something that can be done better, and comments from an Microsoft Partner later gave a good indication that you really had to pick your battles. My conclusion from the tone would be that a SharePoint 2007 site as a whole was virtually impossible to make fully accessible.

Managing Compliance

Next was a slide with a Venn diagram of automation / documentation / remediation, to manage compliance.

There was a very fundamental point missing though: prevention.

The whole presentation and tone of the day was about fixing things, because we can’t trust people to maintain accessibility.
I agree that regular people (content authors) aren’t going to learn about accessibility, but so what? There are simple things you can do to a CMS interface to prevent problems in the first place.

Still, the event is organised / sponsored by a company who makes compliance management software, so I guess that’s to be expected.

ARIA (and JavaScript required?)

Thomas gave a pretty good (and practical) overview of the WAI-ARIA spec being used in practice. Some people might have found it a bit technical, but it is necessary to know a little about ARIA in order to understand how & why the interface for SharePoint 2010 is accessible.

I won’t go through the rest of the content on ARIA, there are good ARIA introductions elsewhere. However, that’s a pretty fundamental point to think about, SP 2010 was built targeting WCAG 2, and relies on ARIA to implement accessibility (and therefore I would assume it relies on JavaScript).

I assume this applies to the editing / collaboration features rather than the ‘content consumers’ type user.

Personally, given SharePoints product development timelines (3/4 years between versions) I would have made the same decision. Someone in the audience pointed out that not everyone can use the latest screen readers or browsers, and asked what the baseline for SharePoint 2010 was.

Looking at the whole situation in general, there is going to be a bit of a gap for a while, as developers implement sites that require JavaScript and ARIA, and Access Technology (AT) vendors implement support for ARIA. If you are in charge of a mass-market or public sector site, then you should probably make sure the front-end site doesn’t require JavaScript or ARIA. However, until people do implement sites using ARIA, the AT vendors won’t make it a priority.

The accessibility community as a whole needs to realise the implicit decision about which option is better long term:

1. Make sure pages / applications work without JavaScript.
2. Make sure that the JavaScript works with Assistive Technologies (with a baseline of WAI-ARIA).

These are not mutually exclusive, however, in practice they will be because of the effort required to do both.
I firmly believe that the experience for someone using Access Technology should be as close to the mainstream as possible, otherwise developers will overlook issues that affect a minority audience.

Thomas also noted that keyboard access is important, including documenting the features available. I wonder whether SharePoint has (or can) avoid the cross-platform and AT issues with conflicting keyboard commands?

Resources

Thomas showed some good resources that I’ll be digging into:

The DHTML Style Guide is apparently very helpful for people trying to implement accessible JavaScript, and should help harmonise things across sites.
Thomas also recommend AOL’s AXS library, which can automatically associate keyboard commands to mouse commands.

See also codetalks.org and search for ARIA test cases.

A work around demonstrated how to use ARIA to mark layout tables with a role of ‘presentation’. However, that really feels to me like solving the wrong problem.

A demo was going to be the next thing, but network issues got in the way. Thomas did recommend the Juicy Studio toolbar for things like showing where the document landmarks are. JAWs and NVDA have keyboard shortcuts for showing landmarks, other access technologies should follow soon.

A quick tip was that you can have more than one landmark of the same type, but it needs a unique title /ID.

SharePoint 2010

The next section was presented by Tara Hellier, SharePoint Partner technology Advisor, Microsoft UK. (NB: Tara talked relatively quickly, which is good for an engaging presentation, but I may not have got everything down, sorry!)

Tara started off saying that Microsoft (MS) are aware of many issues in 2007. They had to make a decision, adapt it in a large and disruptive way for the 2007 version, or work it into the next one. The decision was to focus on accessibility in the 2010 version.

Goals

The standards (or guidelines) being aiming for in SP 2010 are:

• WCAG 2 AA (again, the terminology is about Compliance grrr.)
• Section 508 + VPATs. Tara said that Microsoft have released some of these self-assessment statement, however, I can only find this VPAT on POS 2009.

Some of the goals for SharePoint 2010 were:

• Make is usable, understandable etc. (i.e. not just technically accessible)
• Make use of “Classic” accessibility:
  • HTML input fields
  • Labels
  • Headings (every bit of content has a header, I hope that doesn’t mean over-kill?)
  • Skip links for repetitive content
  • Shortcut keys (Uh-oh)
  • The More accessible mode has been kept, apparently for future-proofing. MS test SharePoint with a lot of ATs, but aren’t sure  where they are going in future. (I would have thought that this would actually be for backwards compatibility more than future proofing?)
• Use WAI ARIA, as the semantics for dynamic content.
• Markup: Use an XHTML 1.0 strict doctype, with the emphasis on well-formed (rather than valid). Tara said that it’s very difficult to be valid, the product team were going for clean, usable code, and to support ARIA it couldn’t have been valid. To me, this seems to be a bit of mis-direction, I suspect there will be a lot of SharePoint specific attributes (perhaps even tags) that are automatically added.
• No more Quirks
  • Adopted CSS standards for master pages.
  • Reduce tables (I did note some in a later demo)
  • Improve cross-browser support. IE 7+, FF 3, and working on Safari 3.x (how about 4.x?). No mention of Chrome / Opera.

It’s interesting that they are using the XHTML strict doctype, because that’s likely to make supporting IE6 on the front-end website a little trickier, at least in my experience.

Keyboard shortcuts

The interface is taking a great deal from Office 2007′s ribbon. It has contextual menus, with keyboard shortcuts for the Ribbon keyboard shortcuts, e.g.

• cntl + [ to Jump to tabs
• cntl + [ Jump to last command
• cntl or shift + arrow keys to jump between groups.

There are also other keyboard shortcuts (Accesskeys?), including S for search and W for welcome. Unfortunately I missed the others. It is a bit worrying, unless I'm missing something these could clash horribly with some access technologies.

ARIA is used around the ribbon, for notifications, text editing, grid editing, rich forms, dialogs etc. In regard to text-editing Tara mentioned something about it being wiki-like, but I wasn't sure if this refered to mark-down editing (unlikely) or something else.

Infopath is an associated product that is used for creating forms, and ARIA semantics has been used for the forms.
Uploading a document now includes aria attributes. (Meaning it's not a standard browser dialogue I assume?)

Tara did a quick demo, and I think this was the first time most people had seen SP 2010.
It has Lost the 'charming blue interface', and the top left has a site actions and ribbon interface. The ribbon is contextual, depending on what's on the page, and (I think) what is focused upon within the page.

You can just click to edit and add text, and then you have the ribbon for the editing controls.

The immediate accessibility issue I noted was the priority given to the font-based styling instead of using structured markup. It's the same in Word 2007, because the styles are hidden away, it's makes it much less likely people will use semantic markup like headings. I couldn't see from the interface how you would add a heading!

(Picture taken from the SharePoint 2010 site.)

I'll provide some feedback even before the beta: please please include an option to give semantic elements priority and remove things like font-size / color etc. I've written many articles on the accessibility of WYSIWYG editors, just start there...

The menu includes tooltips, and Graeme Whippy of Lloyds TSB asked if they are available to keyboard users, which Tara wasn't sure about.

Then someone behind me asked if they could install JAWs on the laptop so that they could try it. Now, I can understand some frustration at this stage if you can't see the presentation. However, the question was asked fairly aggressively, and it wasn't something that Tara had control over. No-one was going to get to try it out today, which is partly why much of the presentation was based on screen shots. The issue really came down to 'audio description', I think Tara is new to the accessibility world and wasn't used to describing her slides. (That takes some practice, I still miss things off.)

There was another question along the lines of "Can you add an image using the keyboard" which Tara wasn't prepared for. I didn't think about it at the time, but the keyboard short-cuts above are exactly how you would do that!

The real answer to these questions was that there will be a public beta of SharePoint 2010 which will be available very soon. It's not exactly easy for most people there to install any version of SharePoint, so Nick at HiSoftware will try to create a test environment and AbilityNet are looking to host clinics to work through the issues.

The call to action was: please try it out and feedback to Microsoft.

"Web Content Creates Risk"

Thomas again, talking about and demoing HiSoftware's products, which cover privacy, accessibility, social media & collaboration, brand 'corruption', and security breaches.

I'll skip the first bit, see HiSoftware's site for the overview.

Thomas showed compliance sherif, which has 233 checkpoints out of the box, but these are customisable and can be added to. It is a bigger number than the guidelines because as well as covering both WCAG 1 and 2 (and non-accessibility things), checkpoints are created for site-specific things.

Many of the checkpoints are based on WCAG 2 techniques. It then uses regular expression logic to spot issues in the pages.

The example used was to build a checkpoint to test that the search has a (visual) label.
Firebug was used to find the classname of the search input. (This is where I spotted layout tables and volumous markup.)

A regular expression creator is used to find that item, and sets the software to search for that control and check for a 'linked element'. It looked relatively easy to use for what it's trying to do, which is quite complex.

It also allows you to set what would be reported, which provides a decent explanations of what it is or isn't finding. (Compared to the standard speil from many accessibility checkers.) As a broad point, I've found that any automated check across a site has to be customised for the site, or it will drown you in 'known' results time after time

The report shows the issues found, and apparently it is quite customisable. For me this seems to be a good approach, as you can specify which techniques are in use on the site and look for those, rather than the nebulous method of looking for generic errors. You could probably have profiles of tests as well, e.g. for HTML based standard sites.

Once the issue is found, the software applies a control adapter, (which takes a little while to reload//build'), then the label has been inserted. It showed a slight layout issue, but considering nothing was done to deal with the layout as part of the demo, this should be fine in practice.

Brian Smith asked why would you need AKS 3.0 if SP 2010 is accessible out of the box?
Thomas replied that AKS 3 is aimed at SP 2007, and could perhaps be used for custom controls in 2010.

There was a question about authoring environment, e.g. why have font type editing:
Thomas replied: That's something that MS would have to answer, but AKS for 2010 would be for things like restricting styles. We aren't at a point yet where we can assess what's needed for that yet.

There was a quick demo of inserting a word document. (I noted the use of Word styles such as headings).

There's a workflow built for this demo into SharePoint (with Compliance Sherif) that checks for things like colour contrast, alt text, and use of headings. Thomas notes that the new workflow model is very powerful. There was also an example checkpoint that highlights incorrect use of a logo in a Document.

Round Table Discussion

Nick Wilson (HiSoftware) hosted, with panellists: Tara (MS), Thomas (HS), Robin Christopherson (AbilityNet), Nikki Ashington (Trinity), and Peter Abrams (Journalist).

I have to stress that this is what I managed to get down, I've probably mis-quoted people. My comments are in [square brackets], and corrections are welcome!

Q to Thomas: Is there a plan to look into (scan) content like graphics?

Thomas: We have started looking at OCR technologies for graphics processing. We don't have that now, but it's a good plan.

Q to Thomas asking if there are plans to integrate with Autonomy?

Thomas: Thats why we created a web API, and were looking at partnerships with people who have different scanning engines.

Q to Nikki: Are people holding back on implementing SharePoint due to compliance issues?

Nikki: It's one of the biggest requests, as we are all aware, but it isn't going to meet double-A compliance, even with the AKS (2). It will meet certain elements but not others. We usually propose to meet them as much as possible and do user testing along side. The only way we can be sure is to test with the widest range of people possible. There are parts of SharePoint we are aware are difficult to make compliant.

Robin, are many people asking about test?

Robin: SharePoint is a tool, so we need to be aware that as soon as a designer touches it, it could be compromised. We (Abilitynet) aren't dogmatic about double-A, what matters is real like accessibility. If there are issues, highlight them but you have to evaluate whether they are issues for real people.For example, we've tested double-A sites with awful IA.

Thomas: Something I've noticed is 3rd party controls / widgets, a lot of the vendors don't have basic accessibility knowledge, so we should be giving them feedback and making sure that isn't a problem. If they build a more accessible/successful solution, that should be more sellable.

Q to Peter: What about procurement?

Peter: Anyone looking at developing new sites should include accessibility as a requirement. It's not just the public sector, the accessibility community has to explain the issues to the private sector as well. As new tools come out, like SharePoint, making it easier, this is is a good thing.Going back to the other questions, people are waiting for SP 2010 because of accessibility. Therefore it's important that people take advantage of the beta testing so we don't have to wait again! Don't wait until it's finished!

Q: Does anyone have first hand experiences in implementing SP 2007, what should we keep in mind?

Nikki: There are a lot of current issues. The the reason we have this association [with Microsoft] is because I grumbled a lot about the accessibility. Obvious things include:

• Accessible master pages & layouts are needed.
• Resizing fonts is still difficult to achieve. But with newer browsers having zoom, do we ignore that?
• AKS isn't a silver bullet, but it does help, Compliance Sherif is a big help with that as well.

Q: We've gone through a lot of pain (and testing) to get where we are now. What pain would we have moving to 2010? [The migration question!]

Thomas: I don't have the migration information, but I'm sure that's something that is being worked on.

Tara: There are two ways:

• Migrate it 'intact' with the same look and feel. [I would assume that this means not benefiting from the update, in accessibility terms, at least for the front-end site.]
• Migrate it with the 2010 look and feel. This is where most of the issues will come along.

That's something our partners will be looking at.
Unfortunately we can't promise perfect migration, but we do have great partners who deal with accessibility and can help.

Q: What about the Content web-adapter that we have customised?

Thomas: With the RTE in 2010 being much better for AT, we're still assessing it, and that will be part of the decision process.

Tara: We've had some experience with partners and people already migrating sites. We'll try and publish that feedback, what sort of issues they've had. Keep an eye on the community.

Q: There's a lot of the talk of Silverlight in Sp 2010, what's the story on that being accessible?

Tara: We've really integrated Silverlight in 2010, there are some things out of the box that have been developed with WCAG 2 in mind. In 2007 it was a bit of an afterthought, it's now much better integrated.

Thomas: In terms of scanning, we can parse XAML markup, but we haven't got customers who use Silverlight yet, so it hasn't come up for us.

Q: Does it have a browser and AT baseline?

Tara: I can't give you and answer on that, I'll chat with people internally and feedback via HiSoftware.

Thomas: I'd just like to recommend NVDA, a free tool with the most complaint experience [Arrgg!]

Robin: It's fantastic for testing, and in some ways it's better than JAWs for the browsing experience, definitely watch this space. However, it's not an 'enterprise' screen reader, and doesn't have good support for applications such as Excel / Powerpoint. Therefore the adoption is going to be limited on the wider scale. With Jaws, developers tend to use it in 40 minute mode for testing, so for testing NVDA is very good. As the lady pointed out though, being better than the common tool can be a problem! It's a tricky problem, I would use things like JavaScript and ARIA but not rely on them!

Ouch, Robin's last comment sort of undermines the approach the SharePoint team have taken. However, as I outlined above, I think they've done the right (and necessary) thing.

Conclusions

Overall, SharePoint 2010 looks fairly promising, there have been some major changes and accessibility has been a stated goal of the development. The real test will be the reports when people get their hands on the beta.

A frustration for me was the pervading attitude and terminology around 'compliance', not just from HiSoftware but from Microsoft people as well. Compliance shouldn't be why people create accessible sites and products. For example, post-content checks will become an annoyance to be bypassed for regular content authors. My company Nomensa produce a Content Management System called Defacto. It's not really in the same market as SharePoint, yet, but the principles of the interface design should be similar. We concentrated on making it so that people produce accessible content, and how many post-authoring checks for accessibility or mentions of 'compliance' do you think we have? Zero.

Prevention is key, and that comes down to the authoring interface, so that's what I'll be looking for when the beta comes out.

Another observation is that questions on access technology baseline (from the audience) are a little misleading, the idea with WCAG 2 is to have technology baselines, which Microsoft have been very clear about.

A worrying trend I noticed in how people were dealing with SharePoint 2007's (lack of) accessibility was the reliance on usability testing. Don't get me wrong, usability testing is almost always a good thing to do, I come from a psychology & HCI background after all. However, the method isn't suited to saying whether something is accessible or not, unless you run a lot of tests. The guidelines are essentially "an expression of potential problems and solutions" (from Universal Design), derived from wide-spread feedback and usability testing, and they remain the best way to evaluate whether something will be generally accessible. With that baseline, usability testing with people who have disabilities is a fantastic way to prioritise which issues are most important.

The most important issue that I remain unconvinced about, is the fact that accessibility in SharePoint 2010 still looks like it's extra work.
The best way to make sure accessibility is incorporated is to make it the default way of developing things.

Content is golden

The simple principle is that you should create your content to last.

(X)HTML may have a limited set of elements to represent the vast array of content we want to put up, but it is important to use them, correctly. The separation of content and presentation underpins quite a lot of the accessibility guidelines, and is what enables people using different devices to access web content in different ways. The WCAG Samurai errata makes a more general and explicit expectation that you should know HTML and use the correct structure for your content.

Content, structure, presentation and behaviour

And yet, you often hear developers saying that you can’t separate content and presentation, as the CSS hooks into the content. That’s not entirely true.

The content and presentation are separate, however both are tied to the structure. The HTML structure with it’s content becomes the foundation that you then layer on the presentation and behavior. Perhaps you might even layer on other technologies like Flash.

Making sure that your content is well structured to start with carries a lot of other advantages:

• Re-use

  If your basic content is well structured, clean (X)HTML, it becomes so much easier to transfer it.

  For example, when handing over templates to a client’s development team, I generally have a set of notes that I include as one of the pages in the templates. The base contents are the same for almost every client, but they receive them in the style of their own website because the content transfers over easily.

• You can build functions later

  Well structured source material makes it easier to add functions later.

  For example, although no one could find them without looking at the source code, I added the cite attribute to any blockquote I could, right from the start of this blog. Later, I created a little function to display the cite as a link under each quote.

  Now any quote includes those links, even though I didn’t have the function to start with.

• Transformation

  If you are using well structured content, scripting a transformation of that content becomes much more reliable (e.g. when migrating content).

I’m sure there are others as well, I may add to this list later, especially if there are some good comments.

The blob in the middle

In many large projects that I’ve been involved with, the content is just seen as the blob in the middle, often ignored until it’s too late.

Unfortunately Content Management Systems (CMSs) are like consumer electronics, you don’t know how good it is until it’s too late: after you’ve bought it. Worse still, you could have tens or hundreds of authors pumping out thousands of pages that you know are not accessible.

For example, if your main headings are created with:
<span style="font-size: 18px; color: blue;"></span>

There are very few hooks to deal with that content later. Not only is it using inaccessible inline styling, if you want to change the formating across the site later you’ll need some awesome regular expressions and a lot of luck.

Ok, that’s all very CSS 101, but there are more subtle examples where you should put content above styling. For example, if the bullets on the site appear quite ‘crushed up together’, authors may add a line break after each bullet point. This is something again that could cause issues in content transfer later, whereas changing the styles to suit the authors wishes is better long term.

As well as applying alternative text to images, it is vital that all content authors know how to use the main structural items:

• quotes
• tables
• headings
• lists

And in order for authors not to try and wheedle around this, you need to make sure that the default styles look good, and as they are supposed to (often defined in an organisation’s style guide).

The opposite side to this it to make inappropriate structures look wrong. For example, and font element could be highlighted to the authors with: font {border: 3px red dashed;}. We use something similar for layout tables within the content area.

It should also be possible (within the editor) to apply style variations to these structural elements. In web development terms, that means the ability to apply a class to various elements.

Thinking about it, the next frontier for WYSIWYG editors will be to allow authors to use POSH and apply the data for Microformats.

Apply this to all content

Making good, structured, content doesn’t just apply to HMTL content. Many organisations put up a lot of PDF documents without an HTML equivalent, and therefore they want to put up accessible PDFs.

If you want to consistently output accessible PDFs, send all content authors on an accessible Word training course. If you just send a few central ‘web people’ on an accessible PDF course, they will know how to create accessible PDFs, they just won’t be able to.

Structured word documents

Did you know that almost everything you can do to structure HTML content you can also apply to Word documents? (e.g. apply styles rather than inline formating). Did you also know that this is the best source material for creating an accessible PDF?

The reason a central team can’t usually create accessible PDFs even when they know how, is because they are either sent an unstructured PDF, or an unstructured Word document, both of which takes a lot of time to correct. The worst case scenario is being sent something that was completely image based, such as a scanned in document.

Creating an accessible PDF can take from a couple of minutes to several days.

A typical process in many organisations is:

1. Person X creates a document in Word. They aren’t part of the web team, so they send it to Person Y who is.
2. Person Y knows about accessibility, and how to create accessible PDFs. But they are busy. They look at this 20 page document which does not use Word ‘styles’ or alternative texts, and realise that it will take over a day to sort out.
3. Person Y has other work to be doing, and doesn’t have time to correct the mistakes of Person X.
4. Another inaccessible PDF is put up on the web.

The advice I give out in the policy advice section of Creating Accessible PDFs course is very rarely followed, usually because the person on the course doesn’t have the influence required:

• Create a good Word template that includes all the styles required to follow the organisation’s style guide. Also include anything else that people regularly use as well.
• Make this template available through the Windows domain (which most organisations seem to have).
• Make sure everyone knows about the benefits, such as easier maintenance of the document, and automatic create of table of contents. Make training available (or required) so people know how to use Word properly.
• Get your techies Windows domain expert to lock down the template, so you can only use the approved styles.
• Start rejecting anything that doesn’t arrive using the template.

Unless the central team have the power to reject content that isn’t done properly (or infinite time), the organisation won’t change, and more inaccessible content will be added to the site.

CMS choice

Circling back to HTML content again, the same principle applies to the editing tool used within a CMS. Authors should only be able to apply formatting using the pre-defined styles, so the the editor within a CMS should be restricted.

Unfortunately there isn’t a good WYSIWYG editor yet. By good, I mean produces accessible content by default, supports non-technical authors in doing so, and is accessible in itself. If XStandard were screen reader accessible I would use and recommend it, but I don’t think it is yet (although keyboard accessibility has been added recently).

Since there isn’t a good editor (and no, text areas are not good editors), if you are implementing a CMS or transition to a new CMS, be prepared to put some time into locking down the editor.

Your choice of CMS should be influenced by how well it supports inputing content accessibly, and how cleanly it stores the content. For example, a CMS that uses a JavaScript editor has to do a lot of work to get around browsers bad handling of HTML (they apply inline styling by default). Although that is the approach we use currently (on Defacto CMS), the content is stored as XML without inline styling, meaning the content is clean and accessible.

A good sign is if the CMS allows you to export all the content in XML, as it means it can be dealt with by scripts more easily if you decide to move CMS. Don’t make the mistake of creating thousands of pages that you can only use with that CMS.

Meta data

I would be remiss not to mention metadata when talking about content. Although not my core interest, it’s another thing that is best applied by an author at the time of content creation.

What type of metadata you would want to use varies from project to project, and depends what you want to do with it (e.g. improve and internal search, auto-generate navigation, or enable personalisation). Ideally, you would define what metadata you want to use upfront, and customise the CMS to make that easy.

Some things can be automatically applied (e.g. author), but some things are best done by authors at the time of content creation. For example, applying attributes to stories from an extendable controlled vocabulary. If you are using something to analyse a page and apply metadata automatically, you’ve probably missed the point or found that it’s too late to apply it properly.

Responsibility for content

The responsibility for content on the web site inevitably comes down to the site owner. Although this is delegated to the developers in terms of site creation and configuration, and authors when adding content, it is too easy to make a wrong decision at the beginning. For example, choosing a CMS that doesn’t support creating structured content, or not looking at the wider scope of content creation in other tools.

Whatever the tool, the responsibility of the site owner is to:

• Choose tools/products that support & enforce creating accessible, structured content.
• Choose tools/products that store the content cleanly.
• Make sure the developers are aware of these requirements from the start.
• Make sure authors know how and why they should use the structural elements properly.
• Don’t enforce inaccessible practices (e.g. new windows for external links).
• If you upload Word or PDF documents to the site, make sure all content authors know how to create accessible Word documents, and a central web team person knows how to create and check accessible PDFs.
• Make sure that metadata is defined upfront, and that the interface for applying metadata makes it as easy as possible.

The bottom line is that without a decent editing tool or lots of training for motivated editors, the content will be rubbish to start with.

Technorati Tags:

• editors
• WYSIWYG
• pdf
• content

At this stage, I’d like to ask for any comments, questions or criticisms before I start applying it to editors.

You can scroll down for a link to the checklist, but I feel I have to outline the aim & what it is supposed to do, and hopefully prevent misunderstandings.

Aim and purpose

This checklist is intended to see how well a browser-based WYSIWYG editor will perform in terms of accessibility, usability and output code quality. An intended side-effect of this is that the people creating editors also use this to improve their products. (Creating an editor is a horrifically difficult thing to do, I’d like to make improving them easier.)

Please note: If you want general accessibility guidelines for other products that produce HTML, the best method would be to sue the W3C‘s Authoring tool guidelines. Although the domain is similar, this checklist is very specific and does not have nearly as wide a scope.

Going through the process of scoring an editor against this checklist should indicate how easily it will allow you to set up an accessible site for editing, and help authors (the people using it) to maintain accessibility.

It is not intended as a pass/fail, (although a very low or negative score is not a good sign), so I’m not going to set a score that should be achieved. Although a few items are considered ‘core’ (i.e. if these are not in place, the output is almost certain to be inaccessible), most editors should get a positive score. These things are relative, and with a few tests completed, I should be able to set up a table of results to compare editors, and allow people to make an informed choice.

Process

The document itself is intended to be saved off, filled in and posted, the instructions are on it. Results for the same editor between different people should be very similar, although it is likely that the largest variance will be due to how well people manage to configure the editor. (You could test the default set-up, but the scores are likely to be very poor at the moment).

It’s published under a creative commons license, so others are welcome to use it to publish their results if they wish to.

No one test of an editor should be considered final, and with comments and suggestions we can figure out how to get the best out of each editor, and hopefully feed that back into their development.

Last call…

There are a couple of to-do items left in the checklist (HTML test cases), but I’d like to ask for comments now in case I’ve missed something vital! Please feel free to leave a comment below, or email me (ac at this domain) and I will endeavor to update the checklist.

Without further ado, here it is: The WYSIWYG editor checklist.

The methods of preventing problems tend to fall into three main types:

1. Interface: making it more difficult to create inaccessible content with the interface, either with good defaults, or things like required fields. Generally my preferred method where possible.
2. Presentation: Making inaccessible content look wrong. E.g. nested blockquotes could have a red background.
3. Enforcement: Using scripting or server side processing to highlight and enforce fixes for accessibility issues. Actually my least favourite method due to poor machine detection and potential author-frustration.

The second method I’ve used for a while with developers and during QA, the best article I’ve seen about it is called: BRAT, but for the most part the errors being shown there shouldn’t be possible to create with an editor anyway.

Going through various aspects in roughly the WCAG 1 checklist order:

Suitable alternatives

An invisible aspect for most people, alternative texts have to be enforced, but also, it isn’t that easy to know what to put. If you enforce alt text without helping with the what, the people using it are likely to be resentful and put in random garbage.

What is needed is contextual help, an aid at the time it’s needed most, when you are adding an image. Generally you’d add an image from file, and have a title and/or description field like this:

To encourage better use of alternative texts you would have to tackle it in several ways, whilst ensuring you don’t make it any harder to add an image. As well as training (i.e. telling people why they should include text alternatives), I would provide two layers of help:

Renaming the label “Alternative text” actually says what it is (an alternative), without getting it confused with a title, which is often taken to mean caption. I would also added a help icon with the most basic advice in the title, and it would link to a more extensive help page.
(Ironically I’ve used WordPress for years, and didn’t realise that adding a description could be used for what is effectively a longdesc.)

For the help page, I would create something concise from one of the better alternative text explanations (e.g. Jim Thatcher’s or Joe Clark’s).

The alternative text field should be a required field (at a minimum). If the editor is only for the content area, I can’t think of any justification for using null alternative texts, as it is part of the content. If editor is used for more than content, using an empty alt attribute might be needed.

There are certain alternative texts that should be discouraged, but possible, such as file names (ending with .jpg, .gif or .png), texts longer than 100 characters, and perhaps non-dictionary items. It is also a good idea to include alternative texts in any spelling checks that are performed, they can quite often go unnoticed until it turns up on Google images or you check the site in an alternative device.

If the editor allows the additions of other non-text objects (e.g. multimedia) then alternatives should be similarly enforced.

Headings

The checkpoint is to: Use header elements to convey document structure and use them according to specification. The way that automated checkers have dealt with this has caused some strange and awkward authoring and templating practices. Basically, so long as you don’t descend more than one heading level at a time the automated checks will pass the page. On this basis, pages without headings, or with just levels 1 & 2, or 5 & 6 will pass, none of which are very helpful to people.

My criteria for this is that the main heading of the page should be an h1, and the other headings should mark the structure of the document in a why that helps understanding and navigation. Think of headings as creating an automatic table of contents and you shouldn’t go far wrong. Using headings ‘according to spec’ usually aligns with an understandable structure, but shouldn’t subsume it.

Perhaps it would be possible to detect if the content is of a certain length (e.g. over 300 words) and show a post screen for the heading, such as the document outline example above.

For the purpose of an editor, it is common for the main heading to be defined as part of the page setup, rather than in the editor. If that is the case, the interface could be restricted to only show from h2 onwards.

It is also important to make sure that authors don’t tend to use the wrong headings because of how they look. On one client site the authors preferred the look of h3s because they were smaller and bold, and used them rather than using any h2s (which were large and orange).

As well as making sure that using headings correctly looks right (and encouraging their use), you could add some script based checking. Perhaps something that creates an array of headings in the content area and checks for any headings that descend more than one at a time. Then add a class to erroneous headings that makes them look very wrong, e.g:

.heading-error {
   border: 1px #f00 dashed;
}
.heading-error:after {
   content: " - inconsistent heading level.";
}

Considering IE’s support for generated CSS content, a JavaScript equivalent is probably more effective.

The final check is that people aren’t creating defacto headings, e.g. a line of bold text. Again a JavaScript style check for any paragraph, div or line on it’s own that is wholly bold or strong would do the trick.

Lists and quotations

There is little an editor can automatically do to detect when someone should be using lists or quotations but is not. Detecting several instances of dash-space on new lines might have some limited value. In a similar way you could detect paragraphs surrounded by quote marks. However, neither of these are particularly robust ways, and should not be enforced or relied on.

I wrote about using a ‘quote’ button rather than an indent button in a previous article, and the editor should not allow nested quotes. If for some reason it cannot enforce that, you could set the CSS to prevent people doing that:

blockquote blockquote {
   background-color: red !important;
}

Link names

Link names should be descriptive of the target, which is difficult to automatically assess, but there are a few checks that could be run either whilst editing, or an on-save check.

A script could check each link on the page (ideally including all links, not just those in the content area), and do the following tests:

• Check for common non-descriptive names, such as “more”, “read more”, “click here”, and “here”.
• Compare the link text and URL for all a elements, and highlight any where:
  • The same URL has different link text.
  • The same link text has different URL.

Keywords first

It is helpful to put keywords first in any particular listing, whether it’s a list of links, or the headings on a page. If each link in a list of chapters starts with “Chapter”, it’s difficult to scan through visually, and even harder aurally. (Ahem, this page of all the WYSIWYG articles is a bad example.)

The only check I can think of for this is to use a script to check the first few characters (e.g. 6?), and highlight this as a potential problem.

Checks not covered

Quite a few items from the accessibility checklist have not been covered here because they either don’t apply to the context of editing a page with a WYSIWYG editor, or they (should) have been prevented from becoming issues by previous posts. However, there are some that I don’t think can be automatically checked or prevented easily, if at all:

• Changes in language: How do you check for a section in a foreign language?
• Use the clearest and simplest language appropriate for a site’s content: One of the most important, but most subjective issues.
• Flickering/blinking images or objects, or those with text within the image: Anything buried in an image or object is beyond any simple check.

Help for authors

Although the editing interface should be self-explanatory, ‘intuitive’ and in general not need help, some people will need it. Help for the meaning of accessibility issues, and what they can do to fix them should be built in as a natural part of the help. Apple’s help in OSX is pretty good because the help icon is usually context-sensitive, i.e. the help page you get depends on what you were trying to do.

Have I missed anything?

I am only one person, if anyone else has any useful tips or ideas, please do leave a comment. There are hundreds of CMSs, and I’ll try in include anything extra that you come up with, assuming that it hasn’t been covered already.

The next step in this series to coalesce the articles into a usable checklist for evaluating the editors.

Technorati Tags:

• accessibility
• editors
• WYSIWYG

Perceptability

In W3C terms: the Interface must be Perceivable, which can be thought of separately from the interaction being possible. For example, if images are used for buttons, they need alternative text. That isn’t just for the controls (usually toolbars), but for the ‘what you see’ content area preview, so that when you’ve added an image with alt text, you can access that as content.

If the interface uses pop-ups or other dialogues, these should also be accessible, so if they use HTML, the form controls and structure should comply with the content guidelines.

The much better known web content accessibility guidelines apply to this, and I don’t think it’s necessary to repeat those here.

Keyboard accessibility

ATAG 2 provides a good outline of what you need for keyboard accessibility, things like:

• You must be able to operate the editor with a keyboard only.
• Navigating through items does not activate them.
• You must allow navigation between controls, and around the editing interface.
• Allow people to save settings between sessions, and preferably be able to import/export those settings.

Assuming the you can navigate around the text with the keyboard, there is one primary issue that you need to get right for editing with a keyboard: Applying styles to a selection of text, and inserting items to a particular location.

The difficult aspect is that you generally need to be able to select a some text, and then move to the toolbar without affecting your current selection. There are three principle methods I can think of that might be viable within a browser based environment:

1. Keyboard short-cuts, e.g. accesskeys or binding keys to functions with JavaScript.
2. A new window for the toolbar, so you can switch from the editing window to the control window.
3. A context menu, so that you can open the possible controls without leaving the selection area.

Although many screen readers allow you to separate the keyboard cursor from the location, but not everyone on a keyboard uses a screen reader, so you can’t rely on that. The mechanisms above would make using a screen reader with the editor much easier anyway.

Keyboard short-cuts

This is my least preferred method due to the major limitations of accesskeys, which is mainly that they tend to clash with user-agent functionality. Using JavaScript to provide the short-cuts wouldn’t be any better, and possibly more flaky with cross browser issues in assigning keys to actions. The ATAG 2 guideline says observe the accessibility conventions of the platform, which may not help very much at the moment, as within browsers they are not consistent yet.

These issues could be overcome by allowing user’s to assign keys themselves, in which case it might be a reasonable option.

New window for controls

Something of a kludge, but one method would be to pop-open a new window that contains the controls, so that you would edit in one window, and switch to the control window to add or adjust things. The advantage is that this is quite simple to do (with JavaScript) and allows an easy switching back and forth.

Context menu

This may be the hardest method to implement accessibly, but it would also be the most usable.

At any point where editing, the user could call up the context menu (there is a dedicated key in Windows, you’d probably have to assign one for OSX or Linux). That menu would have the same options as the control bar/buttons, ideally it would would only show those that are relevant. For example, if there is text selected then the inline options would be available.

This was covered before in a slightly different context for adding structural code. Given the number of options that might be available, it would probably have to be a cascading menu.

Which option would be best?

These three options are not mutually exclusive, in fact, you could happily provide all three. However, I think the context menu is the most beneficial if it can be done, as it would be useful for everyone.

I thought there was going to be more to write for this post, but I think the tricky bit is implementing it, not defining what it should be.

Footnotes

1

At work we have hacked an open source one to make it keyboard accessible, but it wasn’t easy to do.

Technorati Tags:

• editors
• WYSIWYG
• keyboard accessibility
• ATAG

The argument for things like the colour picker are that it allows authors freedom to create pages as they see fit. Perhaps this is true for a personal site, but in a professional organisation, a site should follow a consistent style guide. Adding designed elements should be easy, but only from a pre-defined set.

There are certain things that you can’t add by typing in some text and selecting a drop-down to alter the style, because certain things require the addition of code.

Typical examples include a box-out, quote, two columns, or even all three at once:

The markup for this is fairly straightforward (slightly different from the original, but fine for the example):

<div class="col2">
 <p>
  <img alt="logo" src="logo.gif">
 </p>
 <blockquote>
  <p>Quote text...
  </p>
 </blockquote>
 <p>
   <em>- Project Manager, Some web site.</em>
 </p>
</div>
<div class="col2">
 <div class="box">
  <img class="centered" alt="Screenshot" src="screenshot.png">
  <a href="#">Visit the site</a>
</div>
<div class="cl">&nbsp;</div>

Two column divss, a blockquote, paragraphs, a div with a class of ‘box’, and a clearing div. But how does a WYSIWYG editor produce this kind of markup?

The blockquote is fairly easy, the user selects ‘blockquote’ from a drop down (the one with paragraphs, headings etc) and it wraps the current paragraph in a quote (see structural code).

However, some designs may need a wrapping div around the columns, and creating nestings would get very messy in current WYSIWYG editors, especially browser based ones. What is needed is a mechanism for adding pre-set bits of code that are inserted into the editor, and treated as a uneditable layout areas.

Interface to add layouts

The type of interface needed to add these layout chunks is not a drop-down, as it is inserting something, not changing it. What is needed is a set of buttons, but without taking too much room in the toolbars. I would suggest using a button that when selected, creates an expandable little box of buttons to choose from:

Excuse my poor graphics skills, but I hope you get the idea. This selection of within-page layouts adds in boxes that the editor can fill in the content for, but cannot change the layout without replacing it. (e.g. they can’t drag the sides to affect the size.) They should effectively be hard coded.

Appearance in the editing area

These would then appear in the interface with extra borders, and some way of removing it:

The user can then edit the filler-text (“Paragraph text”) with whatever they want. In this case they could use any standard element, these are just containers.

A more complex version could tackle the first example I used above:

Ideally the editor could restrict which elements were allowed in each section, but at the least the layout areas should be uneditable.

The type of custom features I had in mind for this type of function are within content layouts. They shouldn’t be needed for adding styles to one element (e.g. a quote), as that would be accomplished by styling that element.

Configuration

To create the complex example the site developer would need to incorporate their own template-snippets for use. Hopefully the editor would come with several pre-loaded example that the developer can use, extend, or remove.

How the editor does this is entirely up to it’s usual configuration, although I prefer using XML/XSL files for this purpose.

Technorati Tags:

• editors
• WYSIWYG
• layout
• CSS layout

Allowed & required functions

The first assumption is that tables are for data, not for layout, so any table added should for tabular data, which by definition should have headings. Therefore the creation and editing of a table should allow manipulation of table headings. A simple data table should be the default.

Secondly, as a CSS friendly editor that separates content and style, there shouldn’t be any presentational attributes. Things like cellpadding and cellspacing aren’t needed any longer, unless you need an identical appearance in Mac IE and Netscape 4. So apart from standard attributes, summary is the only other attribute for the table element in the allowed HTML.

Styling tables

In order to have minimal presentational aspects in the interface, you need some pre-set styles. There are two main aspects the user should have control over for most tables, the headings, and the general style of the table, everything else should be data.

The style of the table (likely to be a drop-down of options from the defined CSS files), should provide styles defined around the site’s design. These styles would affect the borders, colouring and fonts.

There also needs to be a mechanism to choose whether the headings go across the top, left or both. (Complex tables are covered below.)

Getting structure and appearance to match

An important aspect of getting non-technical people to use the structure properly is to ensure that how the table looks is right when the structure is right. I’ve seen people creating apparent headings with bold, rather than using headings, even when headings were available and easy to add. There are two main ways to combat this:

1. Use a style definition such as table strong {font-weight: normal;}, or prevent bold/strong being applied in tables by the editor.
2. Ensuring that the styles are defined for headings as requested by the users, and/or by the style guide (if there is one).

Adding a table

The usual ‘add a table’ button gives a good indication of what code will be added, this (bad) example is from FCKeditor is typical:

The default output for the table tag is:

<table width="200" cellspacing="1" cellpadding="1" border="1" align="" summary="">

Not ideal, and missing any means of applying table headings. Dreamweaver has a different approach, and includes a method of adding structural headings:

Still, there are several things here we don’t want, such as the cell attributes, and there shouldn’t be a no-heading option. With a little image-manipulation, this would be my ideal for adding a table:

I have included width, but only for percentage widths. It can be useful to make a table 100% wide, or sometimes a smaller percentage of the width of the container, but working with liquid layouts and variable fonts sizes means that pixel sizing should not be available.

One last thing an editor could (or should?) add for simple tables would be odd-row hooks for styling. I.e. for each even row add a class: <tr class="even">

Although you can plug this problem using JavaScript, this is a small addition of HTML that provides an easy hook for CSS, and is easiest done through a programmatic mechanism such as an editor. Then applying styles to create stripped tables is easy.

Editing tables

One of the usability issues with adding an empty table is that it appears very narrow without content, this example has a caption of “testing”. This is fiddlly, and encourages editors to drag the table or column widths, which in current editors sets the width in pixels.

Tables should not have draggable columns, as there is no real way of converting this to percentages. In a complex table, cols could be used to apply different widths to different columns.

Optionally, Dreamweaver’s “table mode” is a good way of getting around this, although it does make it appear quite different from the final version, as the warning dialogue suggests:

Once a table is in place, there are certain functions that are best accomplished with a context menu (often a right-click). Functions like adding or removing columns or rows need a context menu because the cursor location in the table can be used to identify where the new cells should be added.

Importing data

In practice, it is rare to be creating a table before you have the data. It isn’t easy to type into each cell, so being able to import data is vital for ease of use. However, I would consider this advanced functionality, the above would be a minimum an editor should provide.

There are two main plausible methods: import from a (CSV) file, and cut ‘n paste.

Import from file

The typical scenario would be for a user to have a spreadsheet or similar file that is the source for the table that they want to add. The steps would be:

Select ‘add table’

Using the usual add table button, the file aspect would be another button or tab in the table dialogue.

Select the data

The first aspect is to select the file with the data intended for the table, but there are two potential mechanisms for how much of that file to use:

• Inform the user that they need to save a ‘concise’ version that removes any space above and to the left of the data.
• Preview the data, and allow the user to select the area of the spreadsheet to use.

Obviously the second method is much more difficult to implement (I’ve not seen it done), but would be very helpful.

Apply headings

Using a similar mechanism to the Dreamweaver dialogue above, the user would add the headings and style of the table, preferably with a preview.

Insert table

The table gets added to the content, and after this point is considered part of the content.

I use a macro in my text editor to convert from CSV to an HTML table, it is creating the interface that is the challenging aspect.

Import from cut and paste

Another typical scenario would be for a user to have a source file, and want to copy part or all of it into a table. In this case the user would create a table with the usual interface, select and copy from the external file, and paste into the table.

The requirements for this are simply that the editor supports (kruft-free) pasting into a table, and that it matches the columns and rows or rejects the paste. It is also necessary to allow users to select multiple cells with the keyboard.

Complex tables

I define a complex table as any data table with more than a row or column of headings. Complex tables are a desirable but not required feature, mainly because they are hideously complex to produce properly. Not even Dreamweaver supplies a WYSIWYG editor for complex tables, and it makes no effort to produce the required attributes (at least in the MX version).

Although Joe Clark created a table with just about everything in it, I tend to use a real life client example (and one close to a windsurfer’s heart) of a tide table:

Using Gez Lemon’s excellent table inspector, you can see how the headings have been applied, and I’ve also checked the readout in Jaws, which worked fine:

The type of code this relies on including several elements and attributes, from <colgroups> for the upper headings, to axis for the horizontal headings and (most annoying to edit) the headers attribute on every cell. (See the WebAim tutorial for more.)

That example is produced from a database through an automated template, no-one would want to edit that by hand, so automation of some kind is vital for complex tables. But is it too complicated to do?

One way would be to create a new table from a pre-set selection like the main Dreamweaver interface, which would be a good start, but it could not cover the variety of different tables you might have. It also doesn’t cover the import scenario where you have data already.

Ideally, you would be able to either start with a new simple table, or import data as described above. Then, you would go into a “set headings mode“, and define the relationships.

Defining headings

For example, you would fill in the cells (i.e. put the text in each cell), and then bring up a context menu, set the heading or sub-heading, and select the column/row/cells that it applies to. Forgive my poor graphics skills, but this might be how you would see the tide table example when defining a heading:

I would suggest this is a distinct mode, as it is a phase (or even wizard) that you go through to start with, and probably don’t touch again. There are other functions that would be part of the normal context menu for tables (add/remove columns for example), so one of those options would be “adjust headings”.

This WYSIWYG editing would automatically add IDs for each heading, and defined options of which cells they can apply to. I’m not entirely certain if you could automatically add <col>s and <colgroups>, but it would be worth trying.

Some of these interface methods are new to this domain, are there better ways to deal with complex tables in editors?

Technorati Tags:

• accessibility
• editors
• WYSIWYG
• tables
• HTML tables

The simple interface

It might be considered beyond the scope of an editor to cover image libraries, if so, the simple case should be just that: simple.

From the allowed HTML, we know that most of these fields should not be there:

The three things required at a minimum are:

• Location (i.e. URL)
• Text alternative
• Style

The interface for adding an image should not include depricated attributes such as border, hspace and align. Other attributes that might be allowed, but probably behind another tab are in the custom attributes list (id and longdesc come to mind).

As we saw from dynamic styles, it is best to only show what is relevant in style selections. The editor could either detect styles such as img.alignleft, or allow the developer to configure the styles available. This style would be applied as a class to the image.

When the user has to type or paste in a URL, it would be best to show a preview of the image, or at least some indication that the image is valid.

I am inclined to recommend that editors do not allow authors to re-size images. Using the mouse to grab a corner and re-size makes many people think that the image is being shunk, when it just appears to be have been shrunk. Also, browser do not render re-sized images well.

Image Libraries

Having to cut and paste in a URL to add an image is a pain, and is not nearly as usable as choosing one.

Having a choice of images requires more integration than just slapping in an editor, it requires reading from and writing to the file system of the server. It is also this that is the worst aspect of many editors, either because it adds such a complicated interface, or because it is not flexible in how it integrates with the server.

Browsing an image library

There is one exception I have come across that is (relatively) simple to set up, has a simple interface, and is fairly flexible in where it can browse. This exception is a (now defunct) WordPress pluggin called Iimage browser. Unfortunately it doesn’t work with the WYSIWYG editor, just the code view.

The UK Windsurfing Association site has thousands of pictures which are of several types. It has ‘graphics’ that include logos (100s), event maps (10s), flags (10s), and sailor profile pictures (100s). It also has several years worth of ‘galleries’, consisting of an average of 30 pictures per event, with 10-20 events per year. That’s a lot of pictures, and they need categorising:

This pluggin shows the images from the file system within a reasonably standard web page (requiring JavaScript, but hey, you need JavaScript to have gotten here). The links at the top are your navigation through the folders. It even understands thumbnails, and any image with a matching version preceded by _thb_ is treated as having a thumbnail.

Although the galleries images are held quite separately, I created a symbolic link (like a short-cut) in the file system so that it could read the images, and adjusted the script to use the real location of the gallery images when chosen.

The interface to add an image revolves around adding the code, but is still a good example of what should be there:

If you removed the code panel (as we are aiming at WYSIWYG editors), and added a style drop-down this would be ideal. I haven’t found anything that allows you to add thumbnails with links to the large image as easily.

Uploading to an image library

The ability to add images is a strong requirement as well, as asking non-technical people to use FTP is something of a non-starter, I have tried repeatedly!

The current WordPress functionality works well, you don’t have to leave the editing interface to upload a picture:

The upload interface includes a field for ‘title’, which becomes the default alternative text. I’ve tried to think of a reason why people would apply different alternative text in different situations, but it seems unlikely and I don’t see a problem with centralised alternative text (assuming that you can edit the alternative text after upload).

There should be some guidance on what makes good alternative text, preferably in context, when the user is uploading the picture. A help symbol next to ‘title’, which expands to show concise guidance, such as “imagine you were describing the picture to someone over the phone”. Since editors in this context are only adding images to the content, it is unlikely that a null alt would be suitable, so file names and null alts should result in a warning.

The uploading process should process the image. How many times have you come across non-technical authors uploading a 3MB, 99% quality picture straight from a camera? The picture should be reduced to a size configured by the developer, for example, constrained to 550px square at 75% quality. It would also be useful to automatically create a thumbnail as well.

Another useful feature would be the ability to upload a folder, or set, of images all at once. You’d have to set it off and leave it, but it would be invaluable for galleries. Another option would be to integrate with a popular gallery, making sure that you have access to those pictures as well as the option to upload your own.

Conclusions

Although I am now leaving the analysis of the editors to the end of this series, I know from experience that this is one of the most frustration aspects of trying to integrate a WYSIWYG editor with a real web site (as opposed to just testing).

I will have to scour the internet for plugins for each of the editors to test this fully.

Technorati Tags:

• accessibility
• editors
• WYSIWYG
• usability
• images

With a WYSIWYG interface, there has to be an area that appears as it will when published, which means to change bits within it, you need one or more toolbars. This is an exploration of what those toolbars should do.

Block elements

You could argue that the author doesn’t need to know anything about block or inline elements, they should simply apply a heading (block) or bold (inline). I would agree, but these elements behave quite differently when published, so on balance, I would rather make that explicit in the interface, and mark the behaviour as different.

The default installations of the editors don’t tend to separate block and inline elements, this is a screen shot from X-Standard lite:

The issues I’ve seen with this are that there is a gap between what the user thinks will happen, and what does. I’d like separate mechanisms for applying block and inline elements, and buttons for elements that require a more wizard like approach (e.g. tables and images).

Essentially, when applying a block element (heading, paragraph etc.) it shouldn’t matter whether some text is selected or not, the change would apply to the block element around the cursor.

There are quite a few block elements (headings etc.), so a drop-down widget seems like a good choice:

That drop-down would default to paragraph, and include:

Paragraph

<p>

Main heading

<h1>

Heading

<h2>

Sub-heading

<h3>

Quote (block)

<blockquote> <p>

There are several other block elements that are not in that list because people are either used to them being separate (lists, horizontal rule) or because they require more information (tables). These need their own buttons:

Bulleted list

<ul><li>

Numbered list

<ol><li>

Definition list

<dl><dt><dd>

Horizontal Rule

<hr>

Table

<table> (would require a wizard approach).

Inline elements

Applying inline elements generally requires the user to select a certain amount of text and then select a button which then wraps the text in the appropriate tag (see below). Some editors allow the user to switch-on bold (for example), write, and then switch it off, and carry on writing. ‘m in two minds about that, it means that buttons to not act consistently, but it is a learned behaviour from other editors. So long as it replicates other editors and doesn’t disrupt the markup, it should be ok.

link

<a>

image

<img>

bold

<strong>

italics

<em>

strikethrough

<del>

code

<code>

quote

<q>

subscript

<sub>

superscript

<sup>

acronym

<acronym>

There are a few others that you could include: cite, dfn, ins, or others from the allowed HTML list, but these are the ones I’ve found are most commonly used.

The exceptions are images, links and acronyms; which require more information, however they are still inline items, and follow the same type of rules.

That leaves a useful set of elements to work with, and a means of applying style variations:

(NB: This example was created with TinyMCE, which is missing acronym and doesn’t necessarily produce the correct markup for each item.)

Interface variations for elements

There are certain behaviours that you would want an editor to show that vary by the element being used.

Paragraphs, line breaks and spaces

By default, an editor should make a new paragraph when the user presses return. A line break can be added with shift-return. This applies to headings as well, so that upon return a new paragraph is added below with focus. If the cursor is not at the end of the element, it would split the current element into two.

An editor should not insert non-breaking spaces ( ) if the user presses space more than once, it should ignore the attempt.

Blockquote & Quote

One of the primary interface problems with blockquotes is that they are often referred to as indentation – a very clear problem when trying to get non-technical people to use them correctly! Blockquotes are also tricky because it allows other block elements within it, usually paragraphs. I would suggest that:

• Blockquote must be referred to as “quote”, “block quote” or similar, not indent.
• When a paragraph is made into a blockquote, there is automatically a paragraph inside and below the blockquote, with the focus remaining in the blockquote. This would enable the user to add paragraphs or other elements within the quote and press down to leave the quote.
• There must be a mechanism to add the cite attribute (a URL). This could be:
  • a ‘properties’ command (button or context menu).
  • A wizard approach where a box pops-up with URL and text fields.
  • Something is added to the interface that the user can select, for example:
    

The quote (q) element is an inline version, so cannot contain block elements but should allow the addition of the cite URL.

Lists

There are two primary behaviours needed for lists:

• Pressing tab within a list creates a correctly nested list.
• When the cursor is within the last item and it is blank, pressing return will remove the item and start a paragraph below the list.

Very few editors do nested lists properly, to many times they will incorrectly do this:

<ul>
 <li>Item one</li>
 <ul>
  <li>sub-item one</li>
 </ul>
</ul>

However, a nested list should be within a list item.

Links, acronyms & images

Images will be covered in greater detail later, but all these elements require more information than simply applying a style. An image requires an image location and alternative text, links require a URL, an acronym should have a title. Selecting the button should open up a dialogue to take the appropriate information.

Context menu

A context menu (often right-click in windows, or control-click in OSX) can be a very useful short-cut to changing the selected item. These menus should be dynamic (i.e. change depending on the context), and given browser controls I am surprised that editors don’t usually provide a button for this type of function, as right-clicking can be over-ridden by the browser.

In the same way that the style drop-downs should be dynamic, the context menu would provide access to the additional attributes of the element in question, but only those defined in the allowed HTML.

The JavaScript based editors do not produce a context menu for me (they may on Internet Explorer for Windows), surprisingly neither does Xstandard, although that could be because it’s the beta version for OSX.

A context menu would be a useful addition that allows quick access to attributes of each element, as well as the usual cut and paste.

How the editors do

Previously I have been through each editor at this stage, however, it’s a slow process trying the different configurations for each. Instead, I’m going to leave that to the end, and instead build up a check list of all the points covered in each of these WYSIWYG posts. Then I can test each editor from start to finish, not only establishing the best and worst points of each, but finding the best configurations for each.

Coming soon, how editors should let you add alternative text to images and manage images.

Technorati Tags:

• accessibility
• editors
• WYSIWYG