Speaker: Christian Johansen (Plone, open source on python), Penn State University
Christian is from Weblion. Most of their work now is with content management systems. There are very active with open source communities, most notably on plone.org (and team members serve in key roles on Plone committees)
A CMS incorporates easy publishing + a workflow = explosion of content.
There are over 700 CMS systems out there right now. Most are open source. But technology doesn't matter any more. What really mater is user orientation [training?].
Their goal isn't to create/modify something for themselves, but to integrate their accessibility enhancements into projects core packages (update Drupal templates, add ARIA support) To get the maximum effect make sure to roll it in to the main distribution, not in silos in your own institution. Acceptance of your code is based on meritocracy, including an official review structure/organization.
When choosing a CMS, take the requirements from you clients and shelf them. Instead, focus on community health and vitality behind the project. Is leadership shared? Are new members helped/welcome? What is the size of that community (that is likely the best indicator).
Early on they couldn't hire any Python programmers, so they had to hire and then train their own people, a dubious proposition then, but that has likely paid for itself now (Plone work).
Your role is to make your agenda transparent. If you are competent, consistent, and collegial, you will accrue influence that can allow your requirements to be folded in to full distributions.
Most open source development operates around the bug tracking and ticketing system. You submit your enhancement as a ticket, which is reviewed by the community, accepted or rejected. If accepted, it goes in to the development and testing phase, then release in beta form (then feedback for code changes).
Christian demos the ticket process for a Plone requested change, using some screen shots.
Finally: Your participation in open source communities improves accessibility.
Speaker: Brandon Bowersox (Drupal, open source PHP) OJC technologies from Urbana.
He's done a great deal of work working for the IOWA Department for the Blind. Many of their changes are being rolled in to the Drupal 7 release about to e rolled out in early 2010.
The top layer of accessibility is the content itself – are users prompted to add accessible features when they upload/create content. Do images prompt for alt text? Are users promopted to check external sites they link to.
Then you have the structure- aesthetics, page layout, templates, themes, navigation, search, color, etc.
The lowest layer is the CMS/LMS: the editing and admin tools that come with the product, WYSIWYG editor, etc.
Web design from start to finish:
- Team selection- Include someone from the campus accessibility community- even if that's just a screen reader user.
- Vendor/CMS selection – request a demo copy, require an RFP that includes accesibilty checklists.
- Tech planning – determine features, add-on m odules, if you are going to use ajax, flash, google anaylsics (and make sure you know how to do each bit in an accessible way)
- Garphic design: things like skpi to content links, where titles will be displayed, design colors with contracst at an acceptable level, and your HTML markup and related CSS.
- HTML?CSS theme- related to site wide things, like headings, form objects, ensuring linear reading order
- Production – Iterative testing (which should be happening at each previous step where possible), testing the creation/editing of features
- Testing – If you wait until this phase to check for accessibility, it's too late. This is testing with "real users" for bugs, for most situations
- Launch and Maintenance - . Make sure to have ongoing testing, especially when new tools are added. It is vitally important to solicit user feedback in an ongoing way.
One part of their project for Iowa was to produce their RFP response as a fully accessible PDF.
Some of what they do is provide multiple options for content contribution: the WYSIWYG editor+markup, direct HTML editing, or simple text input with comments (do this or that) for other developers to follow later (say a non-sighted user posting content that needs layout work from a sighted user).
Always consider what parts of an interface can be removed to make it easier for everyone. When new modules/features are being coded/added, do the same type of evaluation to just cut the dross to start with.
They generally only use about a dozen add-ons/modules for Drupal. Although there are thousands out there, it's impossible to keep up and verify that all those modules are natively accessible (and generate accessible content).
They also provide audio snippets of audio books. The use the browser native player by default, but provide multiple other file formats for users to choose to use if that won't work for them.
Making a CMS accessible: make sure you do this for an open source project, and contribute your developments back in to the source.
They updated some ajx menus to be obvious to screen reader users. The also made form error feedback appear at the top of the page, obvious, with links to the problem areas.
Speaker: Mike Scott (OneNet, openSource .NET), Illinois Department of Human Services
About 7-8 years about, IDHS started exploring CMS systems for the intranet and web site. This lead to them (being dissatisfied with what was available) eventually building their own, which is now available via open source.
There are two parts- the part the developers work with, like CSS and templates, to make accessible. The next layer is the content layer- the content the end users make must allow non-technical end users to reliably create accessible web content.
"This is not a knowledge problem, this is a tools problem" Jon Gunderson, University of Illinois
After years of trying to train people to create accessible content, they realized this was the case, and that training alone was never going to get them to their goal of accessible web content creators/content. To get them to remember and apply all the best practices just wasn't working.
The then did a study to compare ten different authoring tools, and content for users to create as a document. Then users were tasked to make the content to see what tools inherently generated accessible content. This revealed that "it's not enough to make accessibility possible, it must be automatic." With Dreamweaver/contribute in particular, it becamse clear the tools were there, but hidden, and not part of the default authoring flow in any of those systems. This lead to their development of OneNet.
OneNet is meant to prevent bad choice to start with (removing the font tags, which aren't semantic). They removed that, and replaced it with structural mark-up options (like headings). As much as possible, all accessibility markup coding needed to happen automatically. They needed to provide a way for users to check their work- some accessibility features must be human checked (does alt text for an image exist isn't the same as making sure it was a useful description). So throughout their tool gives prompts and explanations on what accessibility features needed to be added, and walked them through it.
Right now they are using OneNet to manage about 40,000 pages (intranet and internet) with about 350 contributors.
Pages all have the edit button on them for logged in authorized users. Clicking it open the page in their web based editor. They also wanted to make sure the editor itself was as accessible as possible. There's isn't 100%, but it is pretty close. They've included lot's of keyboard shortcuts, etc. The latest version of JAWS can almost user their editor.
If they choose the wrong heading ( a possible accessibility error) they are prompted about the problem, and offered a fix the can accept or reject.
When it sees punctuation based "fake" lists, it will automatically change it to a real list as soon as a user starts editing it.
It prompts when you add links ("this link text already used on the page" and "please make sure the link text is meaningful).
When images are uploaded, a user is asked about the type of image (decorative, simple, or complex-like a chart or graph).
At the point a user in the workflow marks a page is done (for publishing or the next level of review) all the accessibility checkers are fired up sequentially (but you can choose to use them from the navigation menu as you create content as well). As they accept remediation options in the pop-up window, the actual content in the WYSIWYG is also updated.
When it sees a "fake" list, it will tell you so, and ask you to pick the correct list style (ordered, unordered, etc)
They also do some checking of links to an external document (like a pdf, to ask how they've made it accessible- it's natively accessible, the provide contact information to get an accessible version, or there is an alternate version available somewhere).
Q: So user can all ignore prompts, or is that configurable? What percent compliance with your own rules (IITAA) does this system have? The prompting isn't configurable yet. But some options are lockable (like stopping some user classes from editing html directly). Most people have been beaten in the head about rules, so most users don't ignore this. If you have an approver included in the workflow for creating and publishing content, so they'll send these problem back to the user before the will allow it to be published. Their intranet allows more dismissal/less approval at the final publishing step, so likely less compliance there.
Q: How do you convince your higher ups to contribute code modifications back to the source, and keep a focus on that? A. The reality is that code forks almost never happen, and when it does it's accompanied by fairly grave consequences, basically maintenance upkeep in the long run. If we don't contribute back, each time a major upgrade comes out to the CMS you are using, you have to recode that feature again. Rather than that, it's a better idea to get into a core distribution, because now you've got guaranteed broad community support for the feature you so desperately need that you're willing to develop it on your own.
Form the audience: At Yahoo, they've forked their own version of Drupal out because they've found they can do significantly better than the development community. What about views in Drupal being made more accessible (like views and cck). First they wanted to start with Drupal core. Then they'll work with module developer (like for views) to get them to upgrade their modules to make it more accessibility. Even though they will often use views to create a site for a client, they never actually deploy views for clients to use because it is too overwhelming.
