Creating the HTML5 spec is like usability practice

I haven’t been following the HTML5 progress very closely (how much time does that take?!), but skimming the surface, the friction between developers in the ‘accessibility community’ and some of the core group developing HTML5 is obvious.

Usability tries to optimise for the majority. Techniques such as usability testing (with a representative sample) are oriented around getting the best results for the least expense. The changes to the interface based on usability testing should be kept simple and consistent for the majority of people.
I would guess that writing a spec is also an exercise in trying to keep things simple and coherent.

Accessibility overlaps a lot with usability, and historically web-standards + usability = accessibility.

However, there can be a few things missing, such as alt-text and making sure the keyboard focus is visible. These don’t get noticed by the majority of people, but are needed for people with particular requirements.

During the creation of HTML5 there have been several arguments around what is needed for accessibility, such as whether to make alt text required, and whether table headers are needed.

I completely understand that it’s very difficult to create an understandable, cohesive spec for HTML, so everything possible has to be done to minimise the complexity. However, accessibility is something that has to be included in such as way that developers and authors can create all their content in a way that is accessible.

For example, although complex tables are rare, it is necessary that they can be created in a way that works for everyone. Otherwise Governments and Financial institutions that have to publish content accessibly will have to go elsewhere. (Such as PDF.)

Jeremy Keith summed this up well in 2007:

I am more than a little concerned at the way that studying existing behaviour is being held up as a make-or-break point in discussions around HTML5… By their very nature, accessibility concerns are not going to affect the majority of users.

So yes, it’s useful to pave the cowpaths when you know the common ground, but sometimes you also add another path for those that need it.

WAI-ARIA

There is an argument brewing about whether HTML5 makes WAI-ARIA redundant, and a plea for clean mark-up.

I agree that simpler markup is better, and that native controls tend to work best. I wouldn’t want to use something that creates front-end code based on Java people have written. However, some people (at rather large companies) do, and so you get the lowest common-denominator crap code that Steve Falkner pointed out.

So yes: it would be better if people like Google used cleaner code. However, even if browsers improve the styling of elements so that Google doesn’t feel the need to use krufty code, and HTML5 arrives, we are not there yet.

Working only on a future spec where the native controls don’t exist yet is kind of like saying to people with disabilities: “Don’t worry about your internet access for now, you can have intermittent dial-up for the moment, and we’ll get you broadband in a few years.” That doesn’t cut it.

There are several reasons why WAI-ARIAis needed:

• It bridges a gap highlighted by modern web apps.
• It can be added now without causing compatibility issues.
• It can be added at a function level (e.g. to GWT and JavaScript libraries).

There is another important reason though: It should help simplify the HTML5 spec.

Should HTML5 cover all the elements in WAI-ARIA? For example, should there be a ‘tab’ element that HTML authors need to know about?

There isn’t, and I think that’s ok.

I’ve been reading into this more, and would like to modify my stance. The trigger was this: Semantics are best expressed at the semantic layer (HTML), not at the presentation layer (CSS) or the accessibility layer (ARIA), and the realisation that this is the built-in approach, where as WAI-ARIA is the bolt-on approach.

One thing I’m not clear on though, is what approach JavaScript libraries should take. Historically, people creating (web) applications have been really, really awful at using the limited HTML 4.01 semantics properly. Is adding more elements going to help that? Something like WAI-ARIA can probably be built into a Library more easily than adjusting elements dynamically.

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.

I.e. Accessible Rich Internet Applications with Flash, Flex & Air.

This presentation at Techshare by Andrew Kirkpatrick (Sr. Product Mgr, Accessibility, Adobe) took us through some of the technologies available, with a special eye on the accessibility possibilities and things you need to watch out for. With all the HTML5 buzz/arguments, it is worth remembering that many of the current issues there have already been dealt with in Flash and other technologies.

There were also a couple of announcements here of major improvements to accessibility for two Adobe products.

Andrew had a bit of trouble with PowerPoint and the conference system, I was a little surprised he didn’t PDF the presentation and use Acrobat at full screen? That’s a useful fall-back, but he took it in his stride, and it was of course the demos that people were most interested in anyway.

Quick side question: What’s the most suitable element for interjecting comments into an outline of someone else’s text in HTML 4 or 5? I’m not quoting directly, so it doesn’t fit the usual transcription methods.

Andrew’s Presentation

We define Rich Internet Applications as web based sites with desktop type functionality.
However, it’s a slippery slope definition, as you can have boring desktop apps [e.g. help] and very interactive web applications.

I was involved in the Section 508 at an earlier state, where previously desktop and web guidelines were considered separate, but they are really the same set of issues.

Flash platform History

• Flash player started support of MSAA with version 6 in 2001. These days, AT users should have an expectation of access to flash content.
• Flex provides as set of Flash based controls. [Flex is to Flash what jQuery UI is to JavaScript]. 28 accessible control types (compared to 7 in HTML). Flex developer previously needed to turn on accessibility, now in the [upcoming version 4 release] it will be on by default.
• There are still things that need attending to by the author/developer, e.g. alt text.

Air

Air delivers Flash based apps to the desktop. At the moment, you’ll see a lot of twitter apps, but soon you’ll see things like company HR applications. Allows you to develop in Flash and/or HTML, and deliver cross platform.

Up to now, Air applications have not been accessible. I can announce this week that the next version will have support for accessibility. Uses Webkit, and we can’t yet use that to convey accessibility information yet, so accessibility in HTML isn’t there, but Flash based content is. [Flash more accessible than the HTML, oh the irony!]

Adobe is working with Freedom Scientific and NVDA, plus vendor programme.

Examples

• Creaturediscomforts.org, a Flash app, interesting because they offer subtitles and sign language. But, it doesn’t have accessible controls.
• My story. In Jaws you can use Ins-F5, review the control. Can read through the text. When using the screen reader, it didn’t open player automatically. The developer detected AT, and doesn’t run it by default. Then the user can start it when they want to.
• See other examples at Adobe.com/accessibility/examples.
• Kingtut.org uses the default flash components, skinned, accessible interface with little additional effort.
• Easy-Youtube uses an HTML interface to control the flash.
• CNET TV [sometimes] provides captioning.

Improving the current situation

The User’s role:

• Let developers know if their application doesn’t work for you. (Expectation is that it should work.) If it’s a train wreck, let them know.
• Let developers know if their app works well.
• Don’t turn flash off by default (please!)
• Let Adobe know what works, and what doesn’t, we can campaign on your behalf.

Developers role:

• Following WCAG 2 is a great start.
• Flash authoring tool has panel, but the most powerful flexible way is via Actionscript.

Pertinent WCAG 2 checkpoints

Meaningful sequence

The default order in Flash is determined by the player, often not correctly (depending on the layout). For more complex layouts a human needs to set this order, either in control panel or in actionscript.

aDesigner is an eclipse based tool to help evaluate flash content, including the ordering.

Allow for resizing text

This is not done for you by the player, but you can use CSS to style the text, and then Firefox & Internet Explorer’s browser controls will resize text.

[I asked: what about varying layout?]

If you add a font resizing button, that could also change a ‘state’, which could then change the layout, or do any other change you like.

Contrast

This is really an authoring/design issue, neither helped nor hindered by the technology.

Name, role, value:

Flex and Flash support these automatically, you may not need to do anything. It’s not so easy when you use more complex components (like the accordion in Flex). aDesigner and Inspect 32 can be used to evaluate Flash content.

See the Adobe.com/accessibility site for more, and the blog for the latest things (that haven’t been delayed by the web team).

I’m putting up my notes from the talks I saw at Techshare 2009, and Richard Schwerdtfeger‘s was the first. Please note that this is what I picked up, not direct quotes. [My comments in square brackets.]

Richard is a Distinguished Engineer from Accessibility Strategy and Architecture, IBM, and his talk took us on a journey from the early days of software accessibility, through to tomorrows outlook. Some things I’d heard about before, but it was great to hear about it from a first hand source.

The text from the presentation has been published.

Richard’s Talk

Working in accessibility is a difficult space, like King Sisyphus pushing the boulder up a mountain. But with persistence, we can move things forward. (Pic of poodle pulling over parking meter)

Early Days

In 1990, screen readers could read the DOS buffer. But when going to the Graphical User Interface (GUI), the fear of loosing computer access completely was huge.
For some people, this would mean not being able to work, or not able to keep in touch with friends.

The ‘Windows of Vulnerability’ article written about this, but a small group at IBM research were working on the problem (Jim Thatcher was part of the team), and they built a GUI screen reader.

The writer of the article tried it, and thought it was so good that they should tell everyone. The follow up article was called ‘Making the GUI talk’.
Before this there was nothing, no JAWs etc.

In those days, the methods were based on reverse engineering the semantics of the GUI, which led to inaccuracies. There was no direct API. [This parallels the current lack of application semantics in HTML at the moment.]

In 1995 Microsoft released ‘Active Accessibility’.

We learned what was needed to create accessible applications: I.e. what if the application told you what was needed, rather than what you backwards engineered.

At this time we still needed an off-screen model to recreate the interface for screen readers.

In 1998, the Java accessibility API was released.

This was the first cross-platform API that allowed access to rich text, with no reverse engineering.
It formed the foundation for accessibility for the next decade (e.g. Iaccessible2, Linux’s accessibility model, etc.)

Unfortunately, it didn’t co-inside with what was happening on the web.

The early web years

In 1999 WCAG 1 was released. At that time we were dealing with static documents, and seeing new content always meant reloading the page. We tended to focus on tab and click. You could make websites accessible, but the desktop and web were still very different. It ran in parallel with desktop space, with different people working in each domain.

In 1994 [2004?], I (Richard) was asked to lead accessibility in software [ for IBM?]. The industry was experiencing a shift to Web 2.0 type sites.

For IBM, this shift was a big deal as we do middleware and services.

But how people created the Web 2.0 sites was through the use of CSS & JavaScript. It didn’t address the interoperability issue with HTML, and when writing WCAG 1 we didn’t know how to solve this problem (i.e. things had to work without Javascript).

This was shooting ourselves in the foot, because a rich experience can be more usable for everyone.

The accessibility for HTML was dependant on the HTML semantics, but HTML 4 is not fully keyboard accessible, as only links and forms are keyboard navigable.

This was a major disaster waiting to happen. Compliance with accessibility meant not being as usable as it should be.

Another problem was that new components had no means of providing information to the ATs. Examining this, I (Richard) thought that we need to add desktop capabilities to HTML.

Vendors had other things to do (e.g. security), and accessibly was being pushed to the back burner.
Therefore IBM went to the open source community, and hired Aaron Leventhal and (someone else) and started creating an open community, [I think he mentioned Dojo?], and centred around selling web 2.0 applications.

Industry wide adoption has made ARIA one of the biggest things happening in the accessibility world.

Web Applications

It adds to HTML (before going to the browser and AT) that enables a richer and more flexible accessibility API.

Note that WCAG 2 talks about being robust, i.e. interoperability. You are really leveraging the browser to do a lot of work.
We found a great deal of acceptance amongst engineers at IBM.

ARIA:

• Brings the accessibility and usability of the desktop to the web.
• Allows for full interoperability with AT.
• The technology to meet WCAG 2.

Challenges:

• The switch between WCAG 1 & 2.
• Testing tools needed.
• Web becoming more programmable (mashable).

For example, instead of worrying about a single page that you write, it might be created using widgets, or RSS etc. These things are drawn into a webpage, rather than ‘authored’ in the traditional sense.

Mashups (such as those that use Google maps) can create problems, but people are going to re-use those widgets because they are hard to create.

The future

To fix these, we need to step outside of one size fits all model.

Accessibility needs to become a preference [scripting enabled came to a similar conclusion last year].

IMS GLC/ISO Access for all – standards[?] are moving to the mainstream.

• Resource capability matched to preferences.
• User prefs integrated with device prefs.
• HTML5 local storage could be used to store these preferences.[Could it? I thought it was per-site, like cookies.]
• W3C personalisation roadmap: ubiquitous information.

The web is an open pipeline to the masses.

According to Peter Abrahams, Section 508:

only considers the accessibility of the product and not the accessibility of any outputs of the product. This means that website development tools, Content Management tools, document creation tools or any other tool that produces output that may be viewed electronically can conform to section 508 but none of their outputs do.

A few years ago most CMS products were atrocious both front and back end, providing hard-coded tag-soup and inaccessible interfaces. (From a personal point of view, that is what lead to the development of Defacto, consider that my bias.)

However, most CMSs have improved on the front-end, allowing developers to create websites that don’t break all the WCAG guidelines. (Although often they put a lot of obstacles in the way, and developers don’t always manage to get around them.)

What is almost a universal failure in the CMS market is the authoring interfaces. I’ve tested many, and the bigger the name, the worse the accessibility of the back-end is.

Maybe things are different in the US market, but somehow I doubt it. CMS vendors have conglomerated quickly in the last few years, and interface quality does not seem to be the deciding factor in which survive. Generally the accessibility of the authoring interface is overlooked by almost every buyer, except the more stringent Government or Disability Charities, who then discover they have no choice but to buy inaccessible software.

Perhaps there is a hole in the Section 508 laws, but the result isn’t what Mr Abrahams has suggested, and I’d recommend checking into the lesser know but just as important Authoring Tools Guidelines.

The article implies that CMS vendors have no need to worry about the websites that are produced by their product. However, what has been effective is the commercial pressure of their clients demanding the ability to create accessible websites. Publicly facing websites are highly visible, if only that sort of pressure could be applied to the back-end interfaces, we’d have many better CMS products.

I promised to post up my presentation (and thought I’d add some more links etc) for the people at the event. The Accessibility is usability presentation (2.4MB tagged PDF). is available.

Presentation Overview

Audience of the seminar

A quick round up of the points made, sans examples:

• Intro and Quick definition of terms.
• There are a multitude of assistive technologies, too many to test with.
• You can categorise the ways that people interact with sites.
• Use these categories to understand how page interactions work in various circumstances.
• Research and a case study that imply usability is improved by increasing accessibility.
• Looking at several general usability principles (e.g. simplicity, consistency) you can see these are even more important for people with disabilities.
• Generally accessibility is usability, but magnified. Take advantage of this – testing people with disabilities will find more issues more quickly, and make it easier to pick up the harder to find issues.
• However, there is a gap, things like alt text, HTML structure, visible keyboard focus etc. do not affect the general population.
• These items in the ‘accessibility gap’ do have other effects though. Google and mobile access are the two most obvious at the moment.
• The answer:
  • In theory, accessibility = usability.
  • In practice, accessibility is mostly usability.
  • Legally, they are not the same.

More reading and info

I refered to a few links in the presentation, for convenience:

• Scripting enabled, a great conference last year which include a lot of information and examples with people who have cognitive issues, including videos from the event.
• DRC research, covered by Mike Davies.
• Legal & General case study.
• Transending CSS, future looking, and a great help in getting into seeing structure under your presentation layer.
• Tantek’s Elements of XHTML, see what we can do with markup today.
• Practical plans for accessible IA.
• Why text-sizing widgets are not a good idea.

More videos

The videos in the presentation were pretty straightforward examples, these are more all-round usage videos:

• Introduction to screen magnification.
• Introduction to screen readers.
• Assistiveware podcasts.

First of all, the award is for:

a site, individual or organisation promoting accessible design in 2008.

Accessible design, hmm. Well, the organisations don’t really promote accessible design really, so as nice as it is to be considered with the W3C and Mozilla, they wouldn’t get my vote.

Also, if the award were for standards champion of all time, or a lifetime award, then it would be very stiff competition between Zeldman, Shea, Molly, Meyer & Cederhome (in reverse alphabetical order). But I’m not sure any of them have been promoting accessible design this year?

.net is also a UK based magazine, and I’m hoping a little patriotism might bias people towards the UK based entries

So that leaves:

• Me
• Christian Heilmann
• Julie Howell

Julie Howell is very well known in the accessibility world, campaigning for over a decade whilst at the RNIB, technically authoring the PAS 78 standard and is still right in the thick of things on an upcoming British Accessibility standard. I would assume that, like me, a lot of Julie’s work is for clients, helping them create accessible sites.

Christian Heilmann, “International Developer Evangelist” at Yahoo!, is the creator of accessible versions of Flickr, Easy-Youtube, a method of captioning youtube videos, and even injecting lang attributes into twitter via google!

Perhaps most importantly of all, he has organised the scripting enabled conference, a day of understanding the issues, followed by a day of trying to fix them! (I will be there.)

I’m one of the founders of Nomensa, we’ve been creating accessible sites since 2001. I post here quite a bit, on quite a wide spread of accessibility topics, and in .net magazine. Not incredibly inspiring stuff, but there is one thing that I haven’t mentioned yet. Recently we created the web accessibility and development guidelines (based on WCAG 2) for a well known multi-national, who will be enforcing this with their development agencies for around 500 websites. That should see quite a sea change at that level, as it will be part of the contract for all their new sites to test against and commit to meeting WCAG 2.

Getting that sort of initiative going took not only buy-in at quite a high level in the organisation, but a lot of work to educate the people involved, and willingness to fit accessibility into their current processes and troubleshooting to get past initial problems.

In terms of putting practical tools for accessibility into the hands of developers, Christian wins hands down. However, please do make your own choice at the .net awards.

Josh Lioncourt spoke to Apple‘s Mike Shebanek about the new features:

Understandably, a device as small and compact as the iPod Nano hardly has the processing power to generate text-to-speech (TTS) on the fly… iTunes taps into your Mac or PC’s processing power to generate tiny audio files for the various menus, artists, album, song titles, in your library. When you sync, that information is sent to your iPod Nano 4G.

I wondered about this a couple of years ago based on the patent for the technique, I guess it took quite a while for the various parts of the puzzle to come together. I can see this getting quite widespread use outside of the accessibility community, as it’s a general feature that suits the click wheel very well. Not so with the touch screen, for obvious reasons. You could even produce a Nano-shuffle hybrid that has the click wheel but no screen.

ars technica covered speech in the new Nanos as well:

you have speakable items set up on your computer, the nano will inherit the voice you chose to use. It’s unclear whether this feature will also be part of iPod touches and iPhones.

It seems that the aspects of voice inherit from your system setting. I hope that simply adjusting the speed doesn’t require a whole new batch of the voice files though? Adjusting the speed is quite easy with Voiceover, and I do that every so often. (NB: I am sighted, I just like using Voiceover sometimes!)

Apple have also been active in the Windows accessibility world, working with GW Micro (makers of the Windows Eyes screen reader) to make iTunes 8 accessible for that screen reader. I don’t know that they worked together, but considering the more widespread JAWs wasn’t included, it’s the most likely explanation.

And finally, Apple have published accessibility information in an easy to find place. Most of it seems good, and it’s definately good that Apple has taken the step to actually publish this, however, I couldn’t help feeling that the iPhone page leaves a lot unsaid.

It finished with a link to the “User Guide tagged for screen readers”.  Um, no one who needs to use a screen reader is going to have any luck with the iPhone at this stage!

Bob Easton has a useful test case page, with which I tried in everything I had to hand:

• Firefox 3 with zoom, and regular text-size changes.
• Safari 3 with text-size changes.
• IE 6 & 7.
• Opera 9.5.
• JAWs with IE7.
• Windows Eyes with IE7.
• VoiceOver 2.0 with Safari.

The image replacement techniques were generally fine with a couple of small bugs, most of which don’t appear on Mezzoblue list. Having them as links seems to be problem, and increased font size does seem to be an issue for the Gilder/Levin method unless you start with a small text size.

Problem

When I got to the sIFR method (scalable Inman Flash Replacement), the Windows based screen readers read out the heading twice. I also checked on the official example page as well, just to be sure it wasn’t an old example.

Things may have changes since the sIFR method was introduced, but now most Windows based screen readers (i.e. not VoiceOver) are quite happy to read out the Flash. You get something like:

Flash movie start.
Heading level 3, scalable Inman Flash Replacement.
Flash movie end.
Heading level 3, scalable Inman Flash Replacement.

Solution?

There are two broad ways around it:

1. Hide the Flash content from screen readers.
2. Hide the ‘hidden’ content from screen readers.

I did try (and succeed) in creating an example that hides the actual text from the screen reader, but that’s probably the wrong way to go.

Given that there are still quite a few user-agents (e.g. VoiceOver) that don’t cope with Flash, it would be better to leave the text as available as it is, and make the Flash inaccessible. I assume setting wmode to transparent would do that, wouldn’t it?

I’ve been using the hcal microformat for almost as long as it’s been around on the UKWA events pages, I even added it to the examples in the wild page. I just mean to point out that this is not an academic issue for me, I use it already.

I started with the recommended abbr pattern, but I’ve since moved to using span, for example:

<span class="dtstart" title="20080705">
   Jul 5</span>

This doesn’t actually get around all the issues, but in element-meaning terms, the span is not something that access technologies would need to read out the title of, but abbr definitely is. (It still doesn’t get around the mouse-over issue, but I don’t see a current solution to that, yet.)

Interestingly, the class has been proposed as a way of hiding the parsable data, for example:

<span class="dtstart data-20051010T10:10:10-0100">
   10 o'clock on the 10th</span>

This does not appear to have been embraced:

-1 Tantek. I’m vehemently opposed to putting data in the class attribute. We must find better alternatives. We must not go down the path of invisible (dark) (meta)data – IMHO that principle is inviolable for microformats.

I agree (with a point further up that page) that loading the class attribute is not a common method for this, although I can’t see how that is different from using the title attribute for machine parsable data, especially on an element aimed at people.

Tantek points to the principles, which include: design for humans first, machines second… be presentable and parsable, so I don’t really understand how this fits (or doesn’t) fit those principles. The data is (and should be) hidden from people browsing, but should be parsable by their user-agent.

I don’t see a current “best” solution. It has been circling for a year, and no-one has come up with anything that all are happy with. On a personal site I would rather use something from HTML5 that isn’t valid yet, for example:

<span class="dtstart" data-date="20080705">
   Jul 5</span>

Using an attribute (rather than an element as Lachlan Hunt suggested), feels like it would be less likely to cause compatibility issues in user agents, although I’m happy to be corrected on this.

The actual downside at the moment is that it wouldn’t be supported by anything that people would use to parse microformats.

Unfortunately I don’t have an answer, loading the class does get around the accessibility issues, but would have to be updated in parsers. Using a span element gets around the screen reader issue, in that there is no reason to read out titles on spans. However, it doesn’t get around the screen magnifier issue of incomprehensible tooltips, unless there’s a way of suppressing them in CSS?

The bottom line is that the BBC’s decision to ditch hCalendar is a reasonable one, and every UK/US organisation has to (by law) consider the accessibility of what they produce. For me it’s similar to the table accessibility issues with HTML5. Although using multiple layers of headings (and other ‘edge cases’) are difficult to do without more complex markup like header/ids, it has to be possible to achieve it accessibly. Even if it doesn’t pave a cow-path, or it is difficult for any regular developer, it has to be possible. Otherwise large organisations will have to look elsewhere when producing that type of content (e.g. PDF).