SharePoint 2010 Accessibility Event

The official title was “UK Accessibility Roundtable for Microsoft Office SharePoint Server 2010”, and was a HiSoftware event at Microsoft‘s offices in London Victoria. HiSoftware produce compliance monitoring software for developing and maintaining sites to prevent accessibility, privacy, quality and security issues. The day revolved around several demos of SharePoint 2010 (SP 2010) and Compliance Sheriff™, and fleshed it out with some quite reasonable accessibility information. These are my notes on the event, with a lot of interspersed commentary. I’m sorry they are so long, but there was a lot of interesting things said!

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.