A small part of StatCounter’s Global statistics for browser versions caught my eye:

You might remember from Jacob Neilson’s Alert Box that we were stuck with old browsers for three years:

With IE6′s plateau, it seemed like things were getting worse. Even Firefox (with more tech-savvy users, we assume) is taking the better part of a year to drop under 5% from the release of a new version.

The Google Way

But now there is a new browser in town, with a web application perspective. Let’s zoom in on Chrome, when it updated from Chrome 3 to 4. Light green is 3, dark green is 4:

In a month, Chrome 3 virtually disappeared (5% down to 0.3%), and Chrome 4 took off.

As a web developer: This is fantastic! No more waiting for users to download, they don’t even need to think about it. I don’t need to worry about having multiple browsers installed, because the general population can’t use old versions.

As a user: It’s great… until it breaks. Taking the choice away about when to update a program strikes me as dangerous.

The potential danger is very limited at the moment because Chrome is not bursting with pluggins and isn’t relied on by anything else. However, pluggins are becoming more popular, and upgrades that break web-apps could be a new problem.

We know how well Microsofts upgrades are received when they break things, if Chrome carries on gaining market-share, is it risking the same issues without even giving people the choice of when to update?

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.

I came across a situation recently where a JavaScript widget didn’t ‘work’ on the iPhone. It did technically work, but without knowing about two-fingered scrolling (and when you need to use it), it didn’t appear to work. So how do you differentiate the iPhone (and other touch based devices) from a regular browser?
Well, we all know object detection beats browser detection, but what object would you detect?

The issue in this case was with the Stylish Select jQuery pluggin. It replaces a standard drop-down with a nicer looking one. It is reasonably accessible as well, supporting keyboard use.

However, it creates a div with overflow of auto and a fixed height, which in desktop browsers creates a scroll bar. In the iPhone, it looks as though you can only select the ones that are initially visible, because there is no scroll bar.

In this case there is a nice fall-back: the select box that the JavaScript is replacing. The iPhone (and I assume other mobile browsers) show this in a system-native way.

So the question becomes how do you detect that a touch-based device is in use?

The solution came from this article on Detecting event support without browser sniffing, however, it does more than I was looking for, and wasn’t aimed at touch based detection.

I put together a little script that so far, seems to do what I’d like:

function isTouchDevice() {
   var el = document.createElement('div');
   el.setAttribute('ongesturestart', 'return;');
   if(typeof el.ongesturestart == "function"){
      return true;
   }else {
      return false
   }
}

Currently this script gives good results for:

• IE8 / Win (no event detected)
• FF 3.6 / Win (no)
• Chrome / Win (no)
• iPhone 4.0 (yes)

I originally picked ontouchmove as a fairly advanced touch event, but Google’s Chrome started firing for that event. I’ve moved to ongesturestart which works for now, but may also be used in Chrome later.

If you have another device or browser, please try the test page and let me know the results.

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.

Joel Spolsky – Keynote

Joel’s keynote was on the theme of simplicity vs power, or rather, the third way.

I’m afraid that this is my interpretation entirely from memory, but essentially:

• A couple of fundamental assumptions are that users do not like to make decisions, and that just about every design decision should lead to the user being more likely to get laid.
• There has been a great upswing in simple interfaces, at least partially lead by 37signals. (Perhaps another contributory factor is the rise of internet applications? Services that can do one thing well.)
• However, some types of commercial applications (e.g. bug trackers) will need to cover the 80% of features that aren’t covered by these ‘simple’ applications. Alhtough 80% of people use 20% of the features, they are often different features. Otherwise you are cutting off too many people.
• Creating elegant code often takes more time and thought that simply typing out standard code. NB: Elegant was defined as doing things well, and making it look effortless.
• Creating elegant interfaces also takes more work, both in creating the UI and often more so in the coding behind it.
  A good example is the Amazon one-click. When you move form the (standard?) method of click, then confirmation screen (then rest of checkout process), you suddenly have more work to do. For example, queuing the order (in case they order more things), allowing undo within a certain time, making sure there’s a default address etc.
• Rather than not adding features to keep an interface simple, keep it simple by not forcing the user to make decisions. The interface should certainly start simple, but allow it to be extended, perhaps on a per client/site basis.

Joel’s assertions certainly match my experience with Content Management Systems, which are probably the hardest and least solved programming / interface problem. Whilst 37Signals have been very successful, I don’t see them tackling CMSs any time soon…)

Michael Sparks – Python

Michael essentially took us through the finer points of Python by demonstrating how you can create the Google-style spelling match function, in 21 lines of code (plus a few books worth of content in text files).

It was really good to see an expert use the Python interpreter well (including running into a couple of problems, and solving them). I’d never really understood how you use it for complex functions before, for example,  indentation matters in Python, and you put it in a command line?? Anyway, that explains the spaces being preferred to tabs thing, and it will certainly help in my dealings with Django. Hopefully Michael can post something about it soon, in the meantime the code is available.

Joel Spolsky – Fogbugz

We had plenty of Joel time today, this was his demo of Fogbugz, where it’s a disservice to describe it as bug-tracking software. It’s obviously modelled on Joel’s copious experience in developing software, and includes things like Bayesian driven email direction, and predicting launch times better than developers. I’m not sure it would work for us (juggling 15 web projects at the same time), but it will certainly make me wish for more next time I look at Trac or Bugzilla.

Reto Meir – Android

I have to admit, the technical side of mobile application development (rather than mobile web development) is still pretty intimidating for me, and doesn’t particularly float my boat. Reto also needs to either increase the font size in Eclispe, or use the ‘only when the cursor reaches the edge’ settings in OS X’s accessibility preferences.

From doing previous presentations I’ve learned the hard way to:

• practice it at 800×600 resolution,
• check it in 1024, and
• even if the projector supports more, keep it to 1024!

On the positive side, it was good to see some use of Google moderator. Not only does it make it easy to ask questions (and for people to vote up the best questions), Reto answered the top ones on the spot, and has since answered them all.

Remy Sharp – jQuery

Remy gave good talk on jQuery (presentation), something I’ve used quite a bit. It was great to include how to creat a plugin, and it explained a few things I’d seen around but didn’t understand. I liked Remy’s approach to the brief of using code,

The things that most interested me were:

• Having looking up “equality without type coersion” (the triple equals).
• jsbin.com looks like a very useful service.
• There’s a good IRC channel for getting help.
• How to add a plugin to jQuery.

Jeff Atwood – Stackoverflow

Jeff’s talk was less on code, and more the experiences around Stackoverflow, I can’t remember of it much specifically, but after listening to lots of podcasts it’s good to put a face to the voice!

Pekka Kosonen - Qt

Pekka’s presentation on Qt was intriguing, partly for the upfront honesty (tackling people’s scepticism about platforms from Nokia), and partly because of the possibilities of Qt.

Although Nokia was presenting about Qt, the platform itself is not originally from Nokia, in fact, it is designed to build cross-OS applications, desktop and mobile. Applications such as Skype and Google Earth have been built with it, so it seems that it can produce native looking applications.

It looks like you have to go whole-hog into Qt development, it’s an SDK, IDE and they may even have server-side compiling of code to for platforms you don’t have. The demo wasn’t incredibly convincing, but it does seem like a an option to investigate if you need to develop desktop/mobile applications across several platforms. See also getjar.

Phil Nash – iPhone

Phil’s presentation on iPhone development wasn’t quite what I expected, it took us through a short history of the language that iPhone development uses (Objective-C), before creating a little app from scratch. Phil’s dry sense of humour and occasionally cheesy slides helped make the first half more entertaining, especially as I wasn’t really target audience and haven’t quite got the different versions of C straight yet.

The outline of Objective C drew a few gasps: garbage collection? It seemed most of the audience are used to higher level languages, and Objective C seems like a step backwards.

However, the impression was improved a great deal once Phil opened up Xcode and put together a quick application. Phil was the only mobile developer who managed this. As well as the support of the IDE, emulation is obviously easier for the iPhone than Android or Qt, because you’re targeting a much more narrow range of devices.

Jon Skeet – Humanity: Epic Fail

The ‘phenomenal’ Jon Skeet presented a very funny look at why programming is generally hard, based on a rant he had recently about time zones. There isn’t much for me to say on this, but it’s worth checking out the presentation and audio on the Stackoverflow podcast soon.

Paul Biggar – How not to design a scripting language

I hadn’t really expected much of this talk, essentially what’s wrong with modern compilers, however, Paul’s enthusiasm really carried it.

Christian Heilmann – Yahoo! Developer Tools

For me the best was saved until last. I haven’t seen Christian talk on this before, and despite reading about Yahoo! pipes and YQL, I just hadn’t really groked it before.

It doesn’t really hit home until you see someone put an example together in front of you, but the upshot is that there are about a 100 APIs (everything from Amazon to Weather) that you don’t need to read.

You select a data source from the right of the console, adjust the ‘selector’, the YQL statement top left, and preview the results in the middle.

If the result is good, then copy the URL from the top right box, and use that with your backend (or ajax/ajaj), and hey-presto.
Example uses are:

• Showing all your disparate content on other sites in one place, for which Christian’s site is a prime example. It’s basically built with YQL, virtually all the content is from other sites! (Presentations, videos, books, blog articles etc.)
• YQLAutoTagger – automatic tag generation with a single line of JavaScript.
• Translate tweets.
• Create a set of Flickr photos from a particular geo-location.
• You can even scrape HTML for redisplay, narrowing the area using an xpath statement.

It uses a SQL like syntax to allow a great deal of granularity, both in terms of filtering things to get just the information you want, as well as using several input sources (URLs) at the same time.

I am not closing the YQL tab I have in Firefox until I’ve used it somewhere! I think this is the closest video on YQL I’ve seen that covers the same content.

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.

Ok, I don’t know much about the music industry, but there is such as huge disparity between what the record labels say and just about everyone else, it’s difficult not to comment. I think that’s probably because their business is over. I’m not even someone who participates in online music sites, these comments come from watching Internet businesses.

Historically, the major record labels have been the gatekeepers. People would listen to a few bands on a few radio stations, and the choice of music was finite. New bands come and go, but pretty much at the whim of the labels. Popular bands (Beatles, U2 etc.) would make the record labels huge amounts of money, and many other (no so popular) bands would benefit from record label support.

The record labels controlled the distribution (records, CDs etc) and generally kept rights to things, so they maintain control.

If you think about the general spending on different bands, it’s been something like this (please excuse my poor drawing skills):

Now, I don’t know the actual figures, but both of these must be logarithmic scales, as a few top ‘artists’ make mega bucks (Black Swan style), and there are many who do it for the love of music and gigging.

Changes

The main changes since the CD heyday have been:

• The digital format and MP3 players have changed how people listen to music, and how it’s collected & stored;
• The internet has made the distribution channel almost free;
• The web has made the long tail of interests supportable, allowing geographically disparate people of niche interests to communicate easily.

What hasn’t change is the record labels, especially in the US, where the RIAA prosecutes consumers: the music industry spent an estimated $1M to prosecute just one of the millions of individuals who use file-sharing software. The futility of this approach is obvious.

The future for record labels seems bleak, and I’m not convinced that even with radical change they would survive.

The future of music distribution

Looking ahead a few years, the role of the record label could be replaced by a marketing function with minimal infrastructure. Internet distribution, on-demand printing of t-shirts, books and even CDs means that scaling from 5 bands to 5,000 bands would be (relatively) easy.

Imagine a site similar to MySpace, but purely aimed at being a music community. A site where bands can sign up for free, create some pages, upload some tracks, upload some designs for t-shirts, and put in their gig dates. The site provides blogging for the musicians, for the end-users it provides forums, sharing of ratings and new music recommendations for end-users. (last.fm does this well.)

The band can select a few give-away tracks, and the others have pre-view clips with purchase buttons next to them. The purchase has to be super-easy, going straight into your music collection.

The people running the site keep an eye on the incoming bands, making sure the right people know about new bands, and taking a cut of all the outgoings. They concentrate on giving the bands a good platform, and the users a great way of finding the music and musical events they are interested in. At this point, the share of money going into music could be much more evenly distributed:

I wonder who will be the first to create this type of site? It could be the current labels, there are moves in that direction. It seems unlikely though, they are too entrenched in scarcity thinking.

The massive stumbling block for anyone else is all the artists who are currently signed up. I suspect that the copyright issues would prevent any currently signed band from moving to a completely online model. Sites like Last.fm and services like Spotify have made the listening and finding aspects much, much better. However, they still have to play by the label’s rules, and probably aren’t able to create the sort of music services I’m thinking of.

Another consideration is that ‘music’ is probably too wide for a reasonable online community, it might be that there are site(s) per genre, even if they are simply white-label style differences.

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.