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’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.

You can run it as a program by installing the Validator SAC:

Validator S.A.C. (Stand Alone Complex) is a stand-alone, easy to install, version of the W3C’s HTML / XHTML Markup Validator for Mac OS X.

Even better, you can install it as a local ‘service’, essentially a web application running on Apache on your local machine. That means you can adjust the Web Developers Toolbar for Firefox to use you local version. In the ‘options’ of the toolbar, go to the ‘tools’ options and adjust the URL of the HTML validator.

It’s pretty straightforward to setup as a local website, especially if you use Apache locally on OSX. (My setup is a little more complex, but the principle is the same).

If you’ve adjusted your hosts file to include http://validator/, you just need to wrap the supplied file in a VirtualHost setting and setup your Apache config to use that.

This allows you to check local sites behind firewalls (or just on your own laptop), and to save the W3C some bandwidth, so I’d encourage standards aware developers using OSX to give this a go.

Having been through it twice now, I’ve also compared it with our internal accessibility auditing criteria. With a few (fairly academic) exceptions, they match up, so I can happily recommend the WCAG1+errata as a statement of current best practice in web accessibility.

Considering our internal criteria are WCAG 1 plus our practical experience when testing with people, that is to be expected.

Previewing the WCAG version 2, I don’t think there will be too much upheaval when comparing one to the other when(ever) they are released, although I haven’t checked the HTML techniques for a while. In any case, WCAG 2′s advantage is that it applies to non-HTML web technology as well, something the WCAG 1 errata is not trying to cover.

Exceptions

• Interim measures: I would still assume that some people are still forced to use Internet Explorer 6 at work, therefore we will still fail for pixel sized fonts for public sites.
• I wouldn’t necessarily fail a site for using frames if they did it well, but I have to say that hasn’t come up yet.

Jesse James Garrett – Beyond AJAX

I didn’t take notes here, but it was an interesting story type of presentation, where the meat was “Here is why you should do user-centred-design”, without actually mentioning UCD by name. Perhaps that’s a little cynical, what he actually said was: design from the outside in (i.e. interface first, then functionality, then technology choice), with lots of online and offline examples.

Someone else’s notes on JJG’s presentation.

Molly Holzschlag – The Broken World: Solving the Browser Problem Once and For All

Again, no notes, but the thrust of the presentation was that there are real, human reasons why browsers are they way they are, as well as being hideously complex things to create. I’d love to have a close look at the ‘class diagram’ she took a snap of on a wall at Microsoft, it looked like a massive 3d cube of wires.

Someone else took notes on Molly’s presentation.

Nate Koechley – High Performance Web Pages

I’d been following the performance research by Yahoo for a while, but still wanted to see if there was anything new, and there was.

Starting with a premise that recent interfaces have to some extent reduced the performance impact of the using modern method and separated CSS and JavaScript, he noted that there are two types of performance when sending a page:

• Back-end: 5% of time
• Front-end: 95%

Most things to improve performance are on the front end.

Cache

I’ll skip the jokes as they won’t work written down, but they went down well

The difference between the first page load and a cached page load are quite dramatic due to assets being cached. The difference (I think for the Yahoo homepage) are:

168K 2.4 sec, to 28k and 0.9 sec.

They did some experiments by setting expiration in the past for an image compared to one that should be cached, the graph of the experiment goes from no-one having it cached, to 40-60%, but no further.

20% have a empty completely cache (presumably new visitors), and yet the images for 40-60% were not cached? Perhaps that was due to the homepage effect in IE they found, where IE doesn’t cache the browser’s homepage.

Cookies

Broad scope cookies also get sent to sub-domains, e.g. .yahoo.com gets sent to finance.yahoo.com, so it’s worth keeping those high level cookies to a minimum.

Parallel downloads

Browsers download several items (generally 2) in parallel, and you might expect that if they downloaded more items in parallel they would be quicker. However, the data didn’t back it up. Doing 2 in parallel is quicker than one, but no further benefit was found for 3 or more.

The main causes are likely to be things like CPU thrashing, DNS lookup times vary by geography, and DNS hostnames may not be cached.

Also, if you divide assets it over different severs, the time goes up dramatically.

12 Rules

The best aspect of the presentation was Nate’s consolidation of the research into 12 rules:

1. Make fewer HTTP requests. It’s the single best thing you can do.

   Combine scripts and CSS files, so you have one of each.

   Use things like CSS sprites (combining images then referencing by co-ordinates), the combined size is smaller, and less requests are made.

2. Use a CDN (Content distribution network)

   For example, Akamai, which is geographically closer to the users, and tend to be cached more (DNS). Start with static stuff, images, css and JavaScript.

3. Add an expires header

   It’s not just for images, if there is no expires header, files won’t be cached.

4. Gzip all your components

   You can really affect download times. 90%+ of browsers support it, and it’s negotiated with the server to check first. The usual methods are usually mod_gzip or deflate, mod_gzip seemed to perform better in their testing.

   It’s good for any text based content. Most large sites do HTML, not all do it for JS & CSS. It is not suitable for images or binary/compressed files (e.g. PDF)

   For the text based formats it always save over half of the file size.

   Use central servers for libraries, e.g. yahoo’s YUi.

5. Put CSS at the top of you’re docs
   • Style sheets block rendering in IE
   • Use link, not import. It seems to defer @import. Although it was the fastest loading time, it had the slowest perceived time. Sorry this one is a bit cryptic, there was a good diagram of it which hopefully will go on the blog soon.
6. Put scripts at bottom

   Scripts block the rendering of everything below them in the page.

   Scripts block parallel downloads… (I missed something here, not sure on the reasoning.)

   NB: ‘defer’ is not considered a solution, it’s doesn’t work well enough

7. Avoid CSS expressions

   Most execute many times, e.g. mouse move, hey press, resize, scroll etc. [I'm still inclined to use one for page max/min width.]

8. Use separate files for CSS & JS

   Whilst this seems obvious, there are actually occasions that you might consider not doing that. Variables include:

   • page views per session.
   • empty vs full cache.
   • Component re-use.

   NB: Home pages (as in browser ones) are an exception, and CSS/JS can be inline for greater performance.

   Post-onload download (not sure if that’s correct) is a method of pre-loading files which you know are going to be used. Such as sequential things like shopping baskets.

9. Reduce DNS lookups

   These can block parallel downloading, use a max of 2-4 hosts, use ‘keep-alive’, so it downloads multiple files in one go without new connections & lookups.

10. Minify

    Be careful with obfuscation, as the re-writing can introduce bugs.

11. Avoid re-directs
12. Turn off ETags

Web 2.0 apps

Client side CPU performance is more of an issue.
Nate showed some tests from a Yahoo mail case study. Using AJAX type methods increased initial time (from 6 to 12 secs), but massively reduced the read mail time (to under 2 secs)

The basic idea is to make sure you test time by task, not by page load.

Live analysis – Tools

• IBM page detailer.
• Fasterfox, measures time and allows you to tweak. (Do you need this when you have Firebug?)
• LiveHTTPheaders (FF ext)
• Firebug (obviously)

Nate also mentioned they will be releasing YSlow, a performance lint tool. From the screen shot, it looks like it integrates with Firebug.

Questions

Someone commented that Apache generates etags based on certain things, if you re-configure without imode, you can re-configure apache.

Question on DNS lookups, could you use IPs to speed things up?
Sounds like it would work, but you’d loose the DNS flexibility. Perhaps script it so that first time it looks up, then works out the IP for further requests?

Question asked about whether there are problems with gzipping content?
A very small percentage of edge case on IE where compression can sort of backfire, but it’s no a huge problem.

Someone found that minified JS isn’t needed if it’s gzipped.
Yahoo’s research is different, they found gzip reduced by another half on top of minimisation.

Someone uses SVG and VML to render complex images.
Yahoo have done some work on that, but not found something they are comfortable with yet.

Richard Ishida – Designing for International Users: Practical Tips

Everything I’ve read about Internationalisation seems to lead back to Richard Ishida of the W3C. I didn’t take notes, but he has published his presentaion.

Richard is an entertaining speaker, and even if you get the basics from the slides, he is well worth seeing in action.

Tantek Çelik, Microformats, Building Blocks, and You

As always, Tantek’s presentation is online, I just tried to keep up with the pace. Even if you’re completely upto date on Microformats, you’ll learn something at Tantek’s presentations, and I’ve moved Microformats up my list of things to do to this site.

Joe Clark – When Web Accessibility Is Not Your Problem

Again, Joe is good with putting his notes online, so I just sat back a listened, somewhat nervously it has to be said.

The reason for my nerves was the knowledge that he was going to launch the WCAG Samurai errata, and mention my review. Not that there is a problem with either, but the mystery surrounding it just made me nervous.

The main content of Joe’s presentation is a call to disregard some of the old WCAG 1 issues that are not (or in some cases should not) be relevant anymore. I hadn’t intended to write an article with similar content recently, but there wasn’t much overlap in any case. Joe had better examples to bolster the argument, I had looked at what people should have in their browsers/user-agents.

Jon Hicks - How to be a Creative Sponge

I have no talent for design, nor a particular desire to do design, but it was very interesting seeing the type of methods Jon uses, and it does parallel the more technical in some respects. For example, Jon was espousing the collection of lots of materials for inspiration, primarily non-web materials such as leaflets and t-shirts. I quite often snaffle away little bits of code for later examination.

Jon’s slides are online, linked in the heading above.

Hannah Donovan and Simon Willison – For Example…

Two quicker presentations here, from people involved with last.fm and lawrence.com respectively, both of which are sites worth investigating if you haven’t already.

Last.fm

Hannah was the first designer at last.fm, four years after the company had started, which caused some problems when they wanted to ‘skin’ something, and in web terms Hannah suggests that “Form ever follows function” (Design for the real world by Victor Papanek).

The whole talk was presented with a refreshing honesty, you really got the impression that you were getting the real, gritty story, rather than one through rose tinted glasses.

A point that confused me slightly was you should expose the functionality to users more and add steps into the process. I think in the specific case she was talking about (making apparent where recommendations come from) she is probably right, but I’m not sure it’s generalisable. It kind of goes against the keynote which showed fairly conclusively that users don’t care how things work in general.

Another useful point was they when using the ‘scrum’ methodology, the 5 minutes of forced interaction between different teams each day was very useful.

Doing local right – Lawrence.com

Simon’s talk was very MTV – quick and packs a lot in. Although someone asked him to do it again at normal speed, I liked the pace.

Simon started with two seemingly unconnected observations:

• Local search sucks.

  Compared to local knowledge, you can never tell if a search result is comprehensive, accurate, or even if the individual results still exist in the real world.

• The decline of traditional news

  This point hits home with me, as I’ve been on the receiving end of press-releases which don’t even include a link to the original article, and you just know that three other sites have published the same one. Searches on Google news tend to bring back many versions of the same thing. It’s very anti-web.

In many ways Lawrence.com tackles these well, it is a local entertainments portal, with events, movies, blogs of citizens, “best bets”, and all are subscribable.

The best thing is the number features, but the integration between them. For example, if an event is classified as an outdoor event, it links through to the forecast.

Lots of data is stored as well, such as the 51 restaurants kitchen hours and open hours.

It’s a good case study for a site with richly tagged and interlinked data.

Simon also showed some examples from the sister site LJworld.com, showing more of the same interconnected features.

So the question is: How do you do it?

• Have a small passionate team
• 5 people sitting within 5 m with a large whiteboard
• The gap between thinking of features and implementing them is measured in hours.
• Have someone else to think about money, just like the barrier between advertisements and journalism.
• Get free interns to do a lot of the legwork (e.g. phoning up all the bars every month to get the latest drinks deals.
• Treat your data with respect, make sure it is properly set up, as you never know how you’ll slice it up in future.

The plug: use Django, which was developed when at the newspaper.

It is optimised for constructing complex data models and creating the interfaces, for data rich sites. People can be inputing data whilst you are creating the front-end web site.

The questions asked (since he had buzzed through so quickly) were:

Q: Could you re-do it at normal speed?
No.

Q: Are they profitable?
The aim was to break even, the were investing heavily early on, but believes they are at least breaking even.

Q: Doable in the UK?
Yes, but no one has yet.

Q: How much did it cost?
No idea, but: The team has increased, and they now sell that CMS to other papers. Ellington is a product on top of Django.

Q: Do you have to start from scratch with Django?
It does tend to assume green-field development, but there is a tool for inspecting via SQL and translating.

Simon wrote up the presentation with links.

Shawn Lawton Henry – Advancing Web Accessibility

Having followed the WCAG & W3C process for a while now this wasn’t particularly new to me, but a couple of tit-bits emerged:

• WCAG 2.0 is unlikely to be fully ratified this year, but shouldn’t be too much later.
• ARIA is in second working draft, and may be out this year.
• Some best practice guidelines for ARIA are coming out soon.
• She has released a book.

Perhaps the most pertinent quote was actually from Joe Clark during the hot-topics panel: They seem to have taken all the comments seriously, even mine!

Dan Webb – The Mysteries Of JavaScript-Fu

Frustratingly this was up against Andy Clark’s presentation, and I was torn, but given my lack of design orientation, I plumped for JavaScript-fu. It was a very useful talk for getting a quick understanding of various JavaScript topics, with an entertaining martial arts (films) theme. Not just the what, but the why you would use something. I finally got how you would use event delegation.

Dan’s slides are up, so I’ll point out what appealed to me:

• DOM methods are like Ninjas, innerHTML is a sumo
• A faster loop method (for node type stuff)
• Get Javascript to build things (e.g. opening menus) when needed, rather than building everything at the start.
• Selenium sounds very useful for browser based testing.
• The Pro JavaScript techniques by John Resig includes a lot of stuff from jQuery.
• Dan’s likely to do a ‘how to spot a bad JavaScript resource’ article soon.

Hot-topics panel

Starring Richard Ishida, Dan Cederholm, Joe Clark and Drew McLellon, compared chaired by Jeremy Keith.

It started off with a few questions on the W3C, which thanks to Richard Ishida’s presence became basically ‘get involved’.

I guess the big news is that Joe Clark is retiring from active duty as a web accessibility advocate. Rather than read my mis-remembered version, I suggest you read Joe’s Trying not to pretend post.

I don’t particularly think that accessibility is ‘handled’ yet, although good progress is certainly being made. However, I’m in the privileged position of being able to continue working in the field thanks to being part of a great team, so I’ll not argue about it!

Other coverage

Other coverage sources:

• Blog mentions from Technorati
• Photos from Flickr, particularly Patrick’s stream, and this one.

Also available is my independent review of the errata: WCAG Samurai Errata Review. Unbeknownst to me, Joe had also asked Gian Sampson-Wild, who’s review is at ReviewSamurai.Wordpress.com, and I will be reading with interest.

In my previous article on responsibilities in accessibility you might have noticed that I’d fallen into the traditional accessibility trap of only really referring to (X)HTML/CSS sites and guidelines. I’m quite aware of other technologies, however, barring one caveat, the same things apply.

That caveat is that you should know what you are doing.

In HTML, when you start off with a basic document, it is accessible. As you apply styling, behaviour or cruft, that is when barriers are added. In HTML, accessibility is staying barrier free.

For other formats, you have to layer accessibility on top, it’s extra.

The two non-HTML web formats I deal with regularly are Flash and PDF.

Flash started as a vector animation format, so making that work with linear devices such as screen readers is quite a job. Making Flash sites accessible is definitely possible (we audit them), but it’s something of a black art. We aren’t the only people producing accessible flash, but there aren’t many others.

PDF started off as Portable Document Format – designed to transfer print versions of documents in an interoperable fashion. It’s somewhat easier to make accessible as it can follow the HTML model more easily. However, depending on the source, it is subject to similar issues as inaccessible HTML.

In any case, a site owner or developer’s responsibility would be to ensure that whatever format you use is made in an accessible fashion. If you don’t choose HTML, be very sure of what you are getting into.

The end user’s responsibility is to check that the format is not accessible before complaining, and know how to use accessible versions of that format.

Just because it’s different to HTML doesn’t make it wrong.

The W3C has defined what to do for accessibility at each ‘end’ (i.e. client side or web site site), but there is quite a lot of overlap, and scant advice on who should be responsible for what.

I’m going to try and show who’s responsible now, and where things should go.

Note: As a base assumption, I take ‘web accessibility’ in the stricter sense of ensuring that people are able to use web sites, regardless of their (dis)ability.

W3C model

The W3C, with responsibility for shepherding web technologies along a useful path, long ago outlined how things should fit together. Their essential components of accessibility include the User Agent Guidelines for browsers and assistive technologies, the Authoring tool guidelines for Content Management Systems and other tools, and the Web Content Guidelines for developers and site owners.

However, in the late 90′s when these guidelines were being developed, they were already starting from a very imperfect place. The accessibility of most sites, tools and browsers were appalling. You probably remember that there are many guidelines that start: “Until user agents” can do this that or the other. The developer wasn’t allowed to use pop-ups, client side redirects, or blinking text (amongst other things).

The next version of the guidelines has tried to avoid this, but it’s interesting that several of the things that they assumed would be fixed at the user-agent end, haven’t been (e.g. allow users to control flickering).

There is no getting away from the fact that you must have standards (or guidelines in W3C speak) for how the various web technologies interact. There are simply too many user-agents for developers to test against. The popular browsers are hard enough to deal with, without the dozens of screen readers, magnifiers, keyboards, voice recognition and other technologies that all create a different experience of a web site.

As Mike Davies said, there has to be trust on each side that the other will perform in an expected way. For progress, you need mutually developed standards, as the WHATWG has demonstrated recently by actually making process in advancing HTML.

The usability gap

Currently, the weight of responsibility for accessibility falls on web site owners, and by proxy, web developers. This is actually harmful for the accessibility of the web in the long term, as it stifles progression.

An obvious example is text-size widgets, a feature on a site that allows the user to change the font-size of the text. In the W3C model, this is superfluous, the user should be able to re-size the text from their browser. In web site accessibility terms, it’s like a spoiler on a Robin Reliant, unnecessary and in effect useless.

However, there is a usability gap at the moment.

You can argue that a text-size widget increases the accessibility of the site because people don’t know that they can increase the text size in their browser. And, in general, people don’t. There are many things that user’s can do to any site (built reasonably well with HTML & CSS), from re-sizing the text to changing or removing the layout, or even applying their own colour scheme. Given the multitude of abilities and preferences there are, this is the only way to have a hope of catering for everyone.

But so few people know how to adapt their user-agents that an impartial observer could conclude that it is reasonable for the site to be responsible these aspects.

But that doesn’t make it the right approach to the problem, and in this case the problem is cross-site applicability.

Best for users across all sites

I’ve spoken before about the limiting business models of certain products. If a site with a particularly enthusiastic developer, or a shed load of cash invests in something that improves the experience of the site for a certain population, that’s great, but should others have to?

If users like a feature on one site because the site becomes easier to read or use, they will miss it (and ask for it) on other sites. But they won’t get it on all other sites, whether it’s because other site owners can’t afford it, don’t care, or for other reasons. It’s not scalable.

There are some things that the site owner (and by extension the developer) has to be responsible for, such as the content, and the technology used to create the site.

Some things the user (and their technology) have to be responsible for, such as rendering the content according to the standards, and knowing that you can click links to navigate. (Yes, this used to be an issue in usability testing a few years ago!)

There are a couple of views that tend to highlight where people think this balance should lie. I’m highlighting extreme versions of these views:

Technical view of accessibility

If it works in Lynx (a text browser) it must be accessible.

User’s view of accessibility

If something doesn’t work for everyone (e.g. the title attribute), you shouldn’t use it.

Neither is ‘right’, but going back to my base assumption, you have to consider what accessibility is.

Accessibility = usability

A common theme, but if you are familiar with the definition of usability, accessibility fits right in. Usability is:

the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.

In web accessibility, the product is the web site, “specified users” are people with disabilities, and the “specified context of use” encompasses their task, knowledge, technology, and ability. Whether you think this is too all-encompassing a definition or not, the bottom line is that a real accessibility issue is when a person (with a disability) can’t use your site, not necessarily that a certain technology can’t.

What makes accessibility complex is that different technologies give the person a different view of the same site. That’s what intrigued me in the first place. There are so many contributing factors at play, from the end-user, their technology (and whether they know how to use it), what the site does, and how that site is produced.

This makes it very difficult to say whether an issue a person has should be fixed by the site, the tools that made the site, the browser/assistive technology, or that the user needs educating. Usability is rarely clear cut, humans are messy and it’s probably better to either create a standard that can work for all, or accept the current situation.

Analysing the gaps

Site responsibilities

Working from WCAG 1 & general web standards, these are squarely in the domain of the site. These cannot (usually) be worked around on the user-agent end:

• Text equivalents.
• Using clear language.
• Separation of content, presentation and behaviour.
• Proper use of semantic elements.
• The site works without client-side scripting.
• Ensure that non-HTML formats are accessible (JavaScript, Flash, PDF, multimedia etc. Note on other formats.)
• Identifying the natural language (and changes to it).
• Using valid code.
• Ensure information conveyed with colour is also available via markup or content.
• Clearly identifying links.
• Consistent and understandable layout and navigation.
• Correct use of labels in forms.
• Ensure images with text have sufficient contrast.
• Specifying the expansion of abbreviations.
• Keywords first for headings and links.
• Supplementing text with graphical or auditory presentations.

I’ve put together a list of categorised WCAG 1 checkpoints if you really want the details. I was surprised by how many don’t come up any more.

User / User Agent responsibility’s

These could be adjusted by the user, although some are currently very difficult to do via a normal browser:

• Prevent the screen from flickering/blinking.
• Expand / contract font size and layout.
• Prevent redirects, refreshes and pop-ups.
• Skip over sets of links.
• Access to useful DOM elements (e.g. title and cite attributes).
• Navigating pages via DOM elements (e.g. Scanning headings)

Filling the gaps

There are really two main gaps, each with a technology and knowledge component. The tech components are that the:

1. Tools to create web sites don’t produce accessible code easily.
2. User agents don’t allow people to customise their experience easily.

The knowledge component of each is that:

1. People don’t know to buy better tools.
2. People don’t know to try better browsers/user agents.

So who’s responsible?

I’m afraid I’m not going to answer that for another two posts yet. In the next post, I’m going to examine the user-agent issues, and see how they could be improved. After that, there is the practical “how do people implement these sites” (the authoring tools).

However, I’m fairly sure that it’s going to be a path. If a site implements something that should be on the user-agent end, it should do so in such as way as to pave the way for user-agents to take over.

Technorati Tags:

• accessibility
• site-owners
• user-agents

The response

Individual issues/comments are either missing or protected (it’s difficult to tell), but the search results for person 35436 (Loretta Guarino Reid?) show that the relative units issue was accepted.

After my comment, the response is:
Status: Resolved (comment accepted).

Great! Err, resolved how? It goes on:

LGR: While much of this is a user agent issue, we know there is some author responsibility. We need to capture that distinction.

I’m concerned that the proposed SC could be satisfied by ignoring the text scaling request altogether.

Discussed in the 19 October 2006 telecon:
Resolution: return 1437 back to team B
WAI-WCAG minutes 19th Jan 2007

I’m not sure who team B is, but if there is a proposed SC relevant to scaling fonts, I couldn’t see it.

With some more internal stuff, it seems that my comment is probably a duplicate of 469:

Discussed in the 25 January 2007 telecon:
accepted by unanimous consent
WAI-WCAGA minutes 25th Jan 2007

Resolution – Pending Response:
{accept}

@@SEE LC-469

I was pleasantly surprised to see a response to the commenter (me):

@@Response to commenter

Although resizing is primarily a user agent function, we have added new success criteria to address the author’s responsibility for supporting text resizing:

Level 2: Visually rendered text can be resized without assistive technology up to 200 percent without loss of content or functionality.

Level 3: Visually rendered text can be resized without assistive technology up to 200 percent without loss of content or functionality in a way that does not require the user to scroll horizontally.

Ok, that seems reasonable for the issue of font-scaling, but I’m not sure it’s practical to put all the layout scaling issues into the corner of the user-agent.

Internet Explorer 7′s zoom doesn’t really cut it from an accessibility point of view, and given the cost of screen magnifiers, I really think it has to be something that browsers take on upto a certain level of magnification (200% ish). Beyond that point, you would have trouble using the computer without a screen magnifier, let alone a web site.

Relying on user agents

There isn’t a good spec (or any spec?) for defining how scalable layouts should work. There is nothing to show user-agents how they should adjust for different types of layout, or for developers to specify what user agents should do.

Scaling up the font sizes to 200% is a good start, but trapped within a fixed layout designed for regular font sizes, I’m not sure fonts are enough. The main problem is that there are so many ways of laying out web pages, from tables, to floats, to absolute positioning, with different units for each method (px, percentage and em being the main ones ).

In my opinion, Opera is the most advanced browser in this regard, and uses two related mechanisms to adapt pages: Zoom from 20% to 1000%, and ‘fit to page’.

Without ‘fit to page’, the zoom works as Internet Explorers, and creates horizontal scrolling . These three pictures show the adaptations that Opera makes with ‘fit to page’ on my homepage at different sizes. At 100%:

At 200%, Opera fits the content to the width, and uses the proportions for the column widths (which shouldn’t be too hard in this case as they are set in percentages, but it works on other units as well).

At 400%, Opera takes on a Zoom layout approach, reducing the content to one column with minimal styling:

That’s all well and good, but there are times when these algorythms can fall down. As Phil Teare pointed out on accessify, the navigation at the top of CNN shrinks in size, because Opera is trying to fit a fixed-width table full of images into the width:

The CNN example is unusual, but there are just so many ways of laying sites out at the moment, unless CSS3′s layout module makes it through soon I can’t see user agents being able to account for them all.

I’m glad relative font-sizing got back into WCAG 2, but I don’t think it’s enough.