In order to help educational institutions to identify and include material for these competencies, we are creating a set of foundation courses that can be readily adapted into an existing program at a college, school or university.

The framework will include a collection of tools:

• Course overviews
• Recommended course dependencies indicating what students will need to know before beginning each course
• Learning competencies describing what students must master in order to receive a passing grade
• Ideas for assignments and test questions that allow educators to measure a student’s mastery of each competency
• Recommended textbooks and readings, including articles from the Opera Web Standards Curriculum and other reputable sources
• A list of helpful resources, tools, and utilities specific to each course that will help both educators and students

Why is it called a framework? Given the velocity at which Web technology unravels, we recognize that required skill sets can change rapidly, and that the best way to keep this material useful is for the education community to enrich it with their expertise and experiences. In this way, the WaSP Curriculum Framework will be a “living curriculum” that we hope would be a knowledge base of required skills.

The framework will include guidelines to help educators around the world develop assignments and learning modules that address issues specific to their classrooms. These independently developed teaching materials can then be submitted back to the WaSP Curriculum Framework for review and potential inclusion in the project.

We are also actively working on connecting with other organizations and institutions to create as comprehensive a curriculum framework as possible.

We encourage everyone to get involved by contributing content to the framework upon its initial release in March 2009. In the meantime, join the WaSP Edu Facebook group to share your insights and participate in the discussion. Of course, there is always the WaSP EduTF public discussion list if Facebook isn’t your thing.

The survey was launched in the second quarter of 2007 and educators in both secondary and higher education were targeted. The survey ran for approximately three months. After many starts, stops, and delays (which included the recruitment of Industry and Educational Professionals to the Task Force), the results of the survey are available.

When Educational Professionals were asked what their biggest challenges to implementing a curriculum for best practices, including accessibility and Web standards, they indicated the lack of appropriate materials and reference materials. With both the Opera Web Standards Curriculum and the Web Standards Project Curriculum Framework in active development, this should no longer be an issue.

Later this year, the Education Task Force plans to run another iteration of the survey. We hope to have multiple translations of the survey at that time. If you are interested in translating the survey into another language, please contact the Education Task Force.

I’ll be honest: over the last 10 days, I’ve learned more about the Acid 2 Test than I ever wanted to know. If you want to do the same, you might start with Acid 2: The Guided Tour.

The short version is that part of Acid 2 is a test for the way a browser handles an <object> element when the data attribute references a URL that returns an HTTP status code of 404. A number of caching rules, mod_rewrite rules and redirects all collided to create a problem with our 404. The cached version of our 404 page was returning an HTTP status of 200. As you might expect, this basically makes the test useless.

Acid 2 was broken. Now it is not. Carry on.

Two years ago, the BSI was sponsored by the Disability Rights Commission to write a Publicly Available Specification (PAS) called PAS 78: Guide to Commissioning Accessible Websites. Publicly Available Specifications are written quickly and “expire” after two years, but because of the popularity of PAS 78, the BSI have decided to update it to become a full British Standard.

We’ve just started work on the draft, which doesn’t yet have a title, although our working title is “encouraging the development of fantastic user experiences for disabled people online”.

Consequently, it’s too early to say what will be in BS8878, which will be released next spring. I can say that it will not tread on the toes of whichever version of WCAG is live then, as it’s a document to help site owners rather than developers. Like PAS 78, it will encourage adherence to current web standards.

Neither can I say who else is on the committee, except that it’s chaired by Julie Howell, and there are representatives from all over industry—broadcasting, banking, legal, education and (crucially) representatives of disability groups, including groups working with those with cognitive disabilities.

Patrick and I gratefully acknowledge our employers, Opera Software and the University of Salford, who are supporting us by paying our travel expenses and giving us time off to attend meetings and write the drafts. They have nothing material to gain by supporting us, and are exercising no editorial control, but are helping to make disabled people’s experiences of the web better.

As a procedural footnote, now that Derek Featherstone has moved role within WaSP to be Group Lead, I’m working with Patrick to be co-lead of the Accessiblity Task Force. Our main projects will be the British Standard, continuing to work with the microformats community testing various date-time patterns with screenreaders, and monitoring the developments in HTML5.

Chris states:

We think it will be useful to anyone who wants to learn or teach client-side web design/development “the right way”, including students and teachers at schools or universities, trainers and employees inside companies, etc. It already has support from several universities and large companies, including Yahoo!

Translations and packaging of the curriculum as PDFs is on the to-do list.

Fanning the fires of the ABBR pattern debate, the developers at BBC Radio Labs announced today that they’ll be removing the hCalendar microformat from their programmes listing pages, pending further accessibility testing or the establishment of a more accessible alternative.

Unfortunately there have been a number of concerns over hCalendar’s use of the abbreviation design pattern. [...] Until these issues are resolved the BBC semantic markup standards have been updated to prevent the use of non-human-readable text in abbreviations.

As with the debate over a year ago, the concerns raised are not about microformats as a whole being inaccessible. They’re not even strictly about the hCalendar microformat itself. The concerns are purely centred around the (mis)use of the ABBR design pattern.

Call me naive, but — for me at least — the problem seems to boil down to a few simple points:

• microformats are extremely useful, and, if implemented in an accessible way, can yield massive usability improvements for all users
• the ABBR design pattern is demonstrably broken — no ifs, no buts, no “it’s an edge case”, no playing the numbers
• a handful of alternatives to the use of the ABBR pattern already exist — for instance, the BBC could quite happily carry on using hCalendar, avoid ABBR altogether, and instead opt to have machine-readable information present in the page as a piece of invisible supplementary data; however, this seems to be a rather inelegant (and not well publicised) implementation
• further alternatives to ABBR have been discussed at length (such as proposals to put machine-readable data inside the class attribute), but no real consensus has yet been reached — meaning that current microformat-consuming tools and services are unlikely to support them.

In many discussions, the problem of microformats and accessibility is often miscast as an either/or proposition. Retorts of “if you have accessibility concerns, don’t use microformats” or “if you don’t want to mark up dates in a machine readable format, don’t use microformats” are a classic reductio ad absurdum, and do nothing to move the issue forward. Why should the desire to provide machine-readable data for tools necessarily be antithetical to the desire not to thrust the gibberish of something like the full ISO 8601 date/time in the face of end-users (as expanded ABBR title that’s read out by screen readers under certain conditions, visually presented as a tooltip to sighted mouse users, or clearly present as clear text in the markup when CSS is unavailable)?

Here’s hoping that high-profile announcements like the BBC’s (and those less public, but nonetheless significant ones) will help create some momentum and a concerted effort to find a robust substitute for ABBR. And, once that’s happened, can we finally take this flawed design pattern out of circulation, educate the early adopters of microformats about the new and improved pattern(s), and move on to bigger and better things?

It’s not for developers so much as end-users; the RNIB say

The Surf Right Toolbar is really for anyone who wants to adjust the way they view content on the web to make it easier to read. This could include people with mild disabilities, the elderly, people with reading problems, cognitive problems, using dial-up, photosensitivity and so on.

Nice big buttons make it easy to turn off Flash and JavaScript, change font sizes, and there are some alternate stylesheets built-in.

I reckon it’s a really useful tool (Patrick Lauke and I called for such a toolbar two years ago at Geek In The Park) so go and download it and give the developers your feedback.

Flame-haired DOMscripting lovegod Christian Heillman, has been experimenting with easy-to-use photo viewer for Flickr and an easy YouTube player.

He’s also provided documentation:

• YouTube player docs
• Flickr docs

Groovy—and great to see the area of cognitive accessibility being addressed.

• excellent support for current standards — (X)HTML, XML, XSLT, CSS 2.1, SVG 1.1
• partial implementations of new emerging standards — CSS 3, HTML 5, and ARIA

More details about the browser’s new capabilities and what they mean for web designers and developers are available over at Opera’s developer community site.