Often a single organization will have multiple staff creating content. The staff member who is most concious of accessibility requirements will often discover content that other staff members have added that are not as accessible as they might be, if only because certain checks cannot be automated. It would be good if Drupal modules provided productivity tools for these individuals who have oversight whether by responsibility or default.
There is of course the workflow, but I am talking about a workflow in which the person who does this checking is not in that workflow (and, quite frankly, does not have the time and resources to be in that workflow), but still wants to be able to efficiently check for issues that sometimes come up.
I did review the list of modules which improve accessibility and did not see such a module.
Some sample things which an accessibility review module might provide:
- For each new image added, show the image, the alt text, any link the image links to, any link to a longdesc, as well as a link back to the page on which the image occurs. Purpose: to review whether the alt text is appropriate.
- For each new link added that is not automatically generated, the link itself and the link text and or image, as well as a link back to the page on which the image occurs. Purpose: to review whether the link text is meaningful on its own.
- For each new PDF or media file added, a link to that item, the link text, as well as a link back to the page on which the link occurs. Purpose: to review whether the item itself is accessible or is accompanied by a second, accessible version.
- For each new table added, be able to go directly to that table and review it. Purpose: to review whether the table is accessible.
Other features:
- Display most recent to least recent for the above.
- Be able to page from one such item to the next without having to return to the index list, in order to reduce clicks by 50%.
- Be able to mark an item as offending, notify the staff member who published it, and unpublish it if appropriate without deleting it.
I don't want to have to review every new web page. I just want to be able to quickly review for common accessibility errors.
As for modules which prevent non-accessible content, the following would be helpful:
- Prevent publishing of links whose link text consists solely of "here" or "click here" or "this" or similar.
- Prevent publishing of tables that don't have heading rows, have heading rows which are joined, have column 1 cells that are joined, or have two consecutive rows with identical content in column 1.
Comments
Could this be an addon to Workbench?
Workbench for D7 - http://drupal.org/project/workbench
The problems I see is that to make this workflow the most efficient, it would have to do diff comparisons between versions of content to only show the accessibility reviewer the differences, and then make the important parts for accessibility much more obvious for easy review.
From what I understand, the focus would not be on issues that QUAIL would catch (or the Accessible Content module), but rather a human review of the tags and labels and alt text that the content authors and editors produce?
Human review
Yes, I am definitely talking about providing efficient human review.
For instance, suppose there is an image of a graph containing specific data. If the purpose of the graph is as an illustration showing the sort of things that would appear in a proposed report, alt text of "Sample graph" would be sufficient. But if site visitors are actually expected to read the graph and understand the data in the graph, then it would be necessary to also provide a table containing the data in that graph.
There is no way to determine that programatically.
More mundanely, it would allow catching of alt text reading simply "A photo".
But for ease of use, I would not want to have to open the alt text in a separate window.
Workbench looks interesting; where is the documentation? I'm guessing you're talking about the Workbench Moderation module.
I like the idea of tracking revisions, and again don't want to be in the position of moderator, but more of a post-reviewer. Still, it might be nice to have an Accessible Review completion state, which could only be set by staff with that permission.
I wouldn't want to have to check things that are simply text, only those things which provide accessibility triggers, e.g., links, images, tables. (This assumes I've set the site up so that staff can't mess with the fonts.)
That is, adding or editing a link, image, table or media triggers setting the accessibility review flag on the revision, until accessibility-aware staff has a chance to review it and turn the flag off.
As a side note, it would be clearer if the page for the Workbench Moderation module had the sentence "It is a flexible system which provides default workflow states like Drafts, Needs Review, and Published. You can also change these states to suit your orgnizations needs." which appears in its description of Workbench Moderation on the Workbench Moderation page.
Anyway, it looks relevant to this discussion, thanks!
Charles Belov
Webmaster
San Francisco Municipal Transportation Agency (SFMTA)
Nice idea
@Charles - I'm not sure if I've seen an overview dashboard like that, but can certainly see the usefulness of it.
I generally point folks to this D.o page for the modules which help with accessibility, but put in links to the wiki too as it's good that these are kept in sync.
As far as an overview goes, I'd suggest setting up Holmes CSS with Drupal as I've described in my blog.
I open up new windows in tabs alot and you can scroll through a bunch of them starting from /admin/content
@Jeff - Interesting thoughts about workbench. Seems like a pretty powerful module. Would be great if this could be incorporated more effectively.
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
Rules
For the American Library Association, we are using Drupal 7 and the Rules module to add Accessibility Review into a simple workflow.
Here is the basic process: Use Rules to check any time a node is saved and to trigger an email if a PDF or DOC attachment is being added to the page. If so, hold the page for review and send an email notice to the reviewers. The reviewers will then get involved and can either approve the use of PDF/DOC (and publish the node) or they can support the content author at delivering their content in a more accessible format.
Based on a meeting we had yesterday, our plan is to write a small addition to Rules to more easily flag when a PDF, DOC or similar file has been added to a page. Otherwise, Rules provides everything we need.
www.pixotech.com
Rules module
Thank you for that reference. I'm finding the documentation to be somewhat opaque; it appears to assume I've already installed the module rather than evaluating whether I would want to do so, and there is a lack of illustrations.
I'm not actually looking to have a module send me an e-mail; I get way too much e-mail already. I'm looking for more of a dashboard function. Still, this may be appropriate for some administrators.
I also don't want to hold up the page, although I might want to hold up the potentially offending document.
Charles Belov
Webmaster
San Francisco Municipal Transportation Agency (SFMTA)
@charles the rules module can
@charles the rules module can instead also alter a field like 'to be checked for accessibility'. Then you can create a view with updated posts and flagged. But I understand you concern, rules is sometimes a puzzle.
Dashboard
I agree. We use flags or taxonomy settings such as 'to be checked for accessibility' or 'awaiting review'. Then we use views to create the dashboard where the reviewers get a list of all pages ready for them to review.
www.pixotech.com
Thanks, both of you
So it does seem like Rules (Drupal 6; Drupal 7 beta) and Views (Drupal 6 and 7, with a caveat for 7) working together would provide something close to the "trust, but verify" solution I am looking for.
The question would then be how best to achieve the additional features I am looking for.
It appears either the Content Moderation module (Drupal 6) or the Revisioning module (Drupal 6 and 7) would provide the difference highlighting. Not sure whether that would be at the WYSIWYG or code level.
Then the last piece would be providing an easy way to view and perhaps to alter the alt attribute without having to do an extra step to expose it for each image individually, such as displaying it as a form field or at least temporarily rendering the alt attribute as a title attribute so it shows up as a tool tip for my review process.
Charles Belov
Webmaster
San Francisco Municipal Transportation Agency (SFMTA)
Diff module
For showing differences between revisions, there is also the Diff module (http://drupal.org/project/diff).
I'm not aware of any off-the-shelf solution for showing and editing the ALT tags in a user-friendly way.
www.pixotech.com
@charles Views for sure. You
@charles Views for sure. You could also use CCK computed field and add in that field some php code that checks the relevant fields and saves a value depending on this outcome.
But computed field and rules are workarounds. What we really might need is something like the following:
a. an 'accessbility checker' button in the WYSIWYG-editor (see in Umbraco the plugin for tinyMCE: http://our.umbraco.org/wiki/how-tos/add-accessibility-checker-to-umbraco...)
b. an entity checker that will check all the entities (rendered) of a node when the node is saved.
c. an warning to the user if there are possible accessibility issues when saving (like required fields in Drupal or the accessilibity checker of Office http://office.microsoft.com/en-us/word-help/accessibility-checker-HA0103...), asking or requiring to improve it.
d. if not required to change: flagging the accessibility warning checks
And for controlled content:
e. unpublish the node or the particular entity (if entity permissions are enabled)
Note that WCAG 2.0 has a less heavy requirement for uncontrolled content (comments, forum, rss): it may stay online, while not accessible for two business days, or with a warning message (http://www.w3.org/TR/WCAG20/#conformance-partial).
EDIT: just reading that the new structure of the accessible content module, will work with entity and node checking (modules "Quail API - Field" and "Quail API - Node" ). Cool! See this issue http://drupal.org/node/1071830 and the D7 version in sandbox http://drupal.org/sandbox/thekevinday/1107936
For differences highlighting: http://drupal.org/project/diff
Useful list
Useful ideas, thanks.
And for controlled content:
e. unpublish the node or the particular entity (if entity permissions are enabled)
The main problem with an automatic unpublish is that it may unpublish timely content that we really need to be published no matter what for legal or customer alert reasons. I really need to have a Trust but Verify/Nag option, or the option only to manually unpublish only the inaccessible portion, not the whole node.
Other ideas:
I'm also wondering whether certain things can be auto-fixed. For example, if a page has
<h3>and<h4>but not<h1>and<h2>whether the<h3>can be promoted to<h1>and then<h3>to<h2>. Some of our staff has their own aesthetic sense and sometimes demotes headings because they think the print is too big. Come to think of it, an outline view might be helpful. But that falls under "nice to have" and not critical. Probably coding a view such that the headings are exposed would do the trick, followed by education.Just brainstorming here.
Charles Belov
Webmaster
San Francisco Municipal Transportation Agency (SFMTA)