Plone and Accessibility

Aaron VanDerlip's presentation from Plone Conference 2006

The following is abstracted from notes used for the presentation “Plone and Accessibility” at the 2006 Plone Conference.



What does accessibility mean?


It might be best to define usability first, as it is a term often used to define accessibility.


The following is a definition of usability from the ISO (International Organization for Standards):

“the extent to which a product can be used by specified users to achieve specified goals effectively, efficiently and with satisfaction in a specified context of use” 1.


So one way to think of accessibility is as an extension of usability. Accessibility, as part of its definition, includes people with disability in the set of 'specified users' and broadens the 'specified context of use' to includes situations where accessibility technologies and techniques are employed.


Now that we have a definition, the next issue is that of how accessibility is determined or measured. Two things you will commonly hear mentioned are W3C's Web Content Access Guidelines, and here in the States, Section 508 Standards.


Looking at the WCAG specifically, the key word is guidelines not standards.

“Standards are repeatable, measurable, and testable specifications that can be used and normative technical requirements” 2.

Guidelines can be thought of as best practices, and are thus somewhat open to interpretation. Section 508 is a standard, and is closer to being a testable standard than WCAG 1.0, but ultimately its standards are regulatory not technical in nature; they do not provide agreed-upon ways to implement or measure the compliance of the implementation, but merely state that sites must be in compliance.


WCAG 2 is supposed to address some of these issues by introducing “success criteria” statements that tests can be written for. There are some software tools that you can use that walk through your site and produce some manner of rating based upon the above-mentioned guidelines and standards. These tools can be big time savers, but they should not be solely relied upon in site assessment.


There are two reasons for this:

Many of the checkpoints and criteria cannot be tested using software.

The checkpoints can be implemented in a way that negatively impacts accessibility, for instance, alt-tags that are irrelevant or overly verbose.


I would argue that site accessibility cannot properly be determined without having an actual human test the site against the guidelines; judgment must still be applied.


So, there are a number of CMS systems that proclaim that they are WAI A, AA or AAA compliant. How is that determined, and how much should we trust these claims? I am guilty of taking Plone's claims of accessibility pretty much at face value, but I will argue that the accessibility features in Plone are built-in and central to the software platform.

I would like to talk briefly about 3 aspects of Plone that ensure that your deployments are accessible out of the box. They are:


  • CMFPlone templates
  • Archetypes
  • Kupu + HTML Filtering



First, CMFPlone templates. This is the collection of page templates that are used to render out-of-the-box Plone, both the management interface and the public-facing side. There has been a lot of work done here to ensure that the code is accessible. First, these pages are based on XHTML and CSS; using standards makes it easier for accessibility technologies to interpret your page's meaning. In particular, XHTML (though Plone uses XHTML 1.0 Transitional) ensures that your document is well-formed, meaning in the most basic sense that your tags are terminated correctly and elements are properly nested. Secondly, the pages are constructed in a way that facilitates sensible content when the page is linearized. Page linearization is a process where a two-dimensional page structure is converted, via a software transformation, into a one-dimensional text string. Pages are read, code-wise, from left to right, top to bottom. This is how many screen readers and search engines interact with your page, and the default Plone template renders a logical reading order.


Here are some other examples of accessibility features that Plone provides, via the core set of templates.

  • Heading navigation: the first H1 is the logo, the second H1 places the user directly in the documents contents. This keeps the user of a screen reader from having to page through all the links in a page. Most of the major screen readers incorporate some kind of heading navigations. So H1 means something more than “really big text.”

  • Skip to content/ Skip to navigation: This allows screen readers to skip the links of the page and jump directly to the navigation or the content of the page. Plone implements both of these strategies to skip navigation.


These last features satisfy the following provision of Section 508:


1194.22(o) A method shall be provided that permits users to skip repetitive navigation links.



*Labels for form fields: Form fields are tagged with the label element which assists in providing context for screen readers. This addresses some points in the 508 Standard specifically and the WCAG somewhat more generally. I will go into more detail about form fields later.

So, if you are heavily modifying the default Plone templates, you do run the risk of reducing Plone's accessibility. The best advice is to use a default Plone site as a benchmark for you customizations, see where and how your customizations change the output, and investigate. If you keep your customization primarily to CSS modifications, your site should remain as accessible as default Plone is. One note – if you need to hide an element from the display, use visibility:hidden since it will still be read by screen readers; display:none removes the element entirely.



Archetypes

Plone ships with a collection of default content types, but often it is the case that the site may need some additional content types. This is where Archetypes comes in. Archetypes is a collection of software that underpins the default shipped with Plone content types, and it is probably the most common way new content types and products are built for Plone. Archetypes' goal is to automate some of the tediousness that comes with creating add-on for Plone. One of the time-saving features of Archetypes is that it automatically creates view pages and input forms for your content.


I am going to focus primarily on the generated input forms.


From Section 508 on forms:


1194.22(l) When electronic forms are designed to be completed online, the form shall allow people using assistive technologies to access the information, field elements, and functionality required for completion and submission of the form including all directions and cues.


And from the WCAG:


10.2 Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned. [Priority 2].

12.4 Associate labels explicitly with their controls. [Priority 2]



So when you create a new content type in Plone it generates an input form. If we examine the HTML this generates, focusing on the Title field for a moment, it looks like this:


<label for="title">Title</label>
<span class="fieldRequired" title="Required">
(Required)
</span>
<div class="formHelp" id="title_help"></div>
<input type="text" name="title" value=""
size="30" tabindex="0" maxlength="255" />



Several things are going on here:

  • Associated labels are generated for input fields.

  • The fieldRequired CSS class which shows up in the visual display as a red square is in a span that contains '(Required)' that is hidden. This is accomplished using CSS so it does not clutter up the form.

If this form is submitted without a required field we get the following:

<label for="title">Title</label>
<span class="fieldRequired" title="Required">
(Required)
</span>
<div class="formHelp" id="title_help"></div>
<div>Title is required, please correct.</div>
<input type="text" name="title" value=""
size="30" tabindex="0" maxlength="255"/>


Several things are going on here:

  • Error reporting on the top of the page (Please correct the indicated errors.)

  • At the field level “Title is required, please correct” text is generated next to the input, so the user knows what to do. This is done for all fields that are editable and required.


This approach has several advantages. First of all, it does not rely solely on color or other visual cues to mark input errors. Second, this approach is not dependent on client site scripting.


The same form validation mechanism is used in the core templates I mentioned earlier. The key is that Archetypes generates this for you automatically.


I would like to argue that the accessibility features found in the core templates and in Archetypes adds an additional capacity that is not often discussed, which is that Plone is an accessible tool for content creators as well. The W3C has another guideline, the ATAG (Authoring Tool Accessibility Guidelines)


From the W3C:

“...the authoring tool be accessible to authors regardless of disability, that it produce accessible content by default, and that it support and encourage the author in creating accessible content. Because most of the content of the Web is created using authoring tools, they play a critical role in ensuring the accessibility of the Web. Since the Web is both a means of receiving information and communicating information, it is important that both the Web content produced and the authoring tool itself be accessible.”


A board member of an organization I work with, who is legally blind, has demoed Plone and was able to use the management user interface to add new content. As I described earlier, Archetypes-based content will create accessible content input forms automatically, so there is a good chance that add-on products will support accessible content authoring as well.



Kupu


The other part of the ATAG, “producing accessible content by default” and supporting and encouraging authors to create this content, is perhaps the biggest accessibility challenge that exists. You start out with a pretty solid foundation, you have been good and used CSS primarily to transform your site's look and now you're ready to turn it over to the users so they can begin adding new content to the site. This is a challenge with so many sites that are built; how do you ensure that content editors, many of whom do not know or care to know HTML, create content that is still accessible?


This is where Kupu and HTML filtering come in. Kupu is the blessed and shipped-with-WYSWIG editor that Plone uses. In my view, for end users Kupu is Plone. It is where content editors spend most of their time. It is the primary tool interface.


How does Kupu help Plone users maintain accessible sites?

  • Provides some boundaries in software as to what code can be entered.

  • When images are added from within Kupu alt-tags are auto-generated, from the description if it exist; otherwise it defaults to the title.

  • You cannot add presentational elements like <font> <center> in addition to form and Javascript elements.

  • Code cleanup and correction, what everyone hates. “What happened to my page?” This code cleanup ensures that pasted HTML and content from other sources “follows the rules”.

Using Kupu guarantees a couple of things:

  • Out of the box, your HTML will be correctly structured most of the time.

  • Out of the box, your HTML will be structural, which means no presentational tags.

  • Images will be properly inserted; the end user doesn't have to manage it.


I know Kupu gets a bad rap for being too restrictive, but its implementation, while imperfect, is deployed in a manner that assures that non-technical end users continue to create accessible and standards-compliant HTML.


Certainly Kupu could be improved, however I would argue that switching editors will not improve accessibility and will mostly likely degrade it unless the prior requirements are met. So, before you go rushing off and leave old practical Kupu think about how it will impact the code in the long run.


Why should you care about what happens to the site after the client takes possession? If they insist on disabling or removing accessibility features, well, they are paying the bill after all! If we roll out sites with non-compliant editors but they give clients more design control, ignoring how that design is implemented, is it our problem?



Accessibility – The carrot and the stick.


The carrot

First, and this is my opinion, I feel that as developers and implementers we should do as much as we can not to exclude populations from access to information or its creation based on disability or technical capacity. As Plone developers and implementers we should honor and respect the tremendous amount of work that has gone into making Plone accessible and educate our clients on how the system accommodates a wide cross-section of the population and the importance of that inclusion. More pragmatically, individuals with disabilities as a group have more purchasing power than the teenagers as a group, so it make solid business sense 3. And finally, most of us will experience either a temporary or permanent disability at some point in our lives. That is the carrot.


The Stick

The landscape of developer responsibility is likely to change due to future changes in the law, for both the US and other countries as they adopt or extend similar measures. What I mean here is that in terms of developing sites that meet recognized accessibility guidelines, it is likely from a legal standpoint for the chain of responsibility to flow back to the developer. So developers are very likely going to find themselves in a similar position to that of an architect in traditional construction. Currently under the ADA (The Americans with Disabilities Act signed in 1990) if you, as an architect, design a building that does not meet ADA requirements, you can be held liable and subject to fines. I would expect in the future to see legislation that clarifies and expands the ADA to be cover the online presences of organizations and businesses. Looking forward, in my opinion the next few years will be big years for Plone and Plone-based consultants as organizations and businesses wise up to the new legal requirements around accessibility.



Conclusion


Plone is free software. The word “free” has of course two meanings, both applicable to Plone. It is monetarily free (there are no licensing fees) – the free as in beer definition. That definition of free has an immediate pragmatic meaning, something that certainly benefits many of the groups I work with. But I want to focus on the second meaning of free, the one people refer to as the “speech” part, which is really about liberty. As members of the Plone community, I feel that the tool we use and develop, because of its focus on accessibility, can have a positive social impact on the community at large. It opens up opportunities for individuals who have so far been excluded from participating online; thus, through the mechanism of lines of code running on computing hardware, we can produce an end result that embodies the ideals of participation, inclusion and equality.


I leave you with a quote by Lawrence Lessig:


“We can build, or architect, or code cyberspace to protect values that we believe are fundamental, or we can build, or architect, or code cyberspace to allow those values to disappear. There is no middle ground” Code and Other Laws of Cyberspace (Basic Books, 1999)


Notes


1.Thatcher, et al., Web Accessiblity: Web Standards and Regulatory Compliance (friends of ED, 2006), page 26

2.Thatcher, et al., page 460

3.Holding, Reynolds. “Missing the Target.” Time.com. October 9 2006. http://www.time.com/time/nation/article/0,8599,1544275,00.html(accessed October 12, 2006).