Paul's feedback on "Selecting and Using Authoring Tools for Web Accessibility"

Shawn and EO colleagues,

About 9:30 PM (pacific time) the W3C wiki page was giving me 504 gateway errors so I'm not sure my review notes of the "Selecting and Using Authoring Tools for Web Accessibility" posted.  My comments below...maybe Shawn will have better luck adding them?  :-)
[cid:C05DE35F-6CFE-4469-B666-75757418E2C8@gateway.2wire.net]
==================

* Selecting and Using Authoring Tools for Web Accessibility - My Observations and Review Notes <span style="color:#808080;">{Paul}</span>

* Andrew is right, this page has a lot of very outdated information :-)  That said, the purpose of the page is still valid, and a significant portion can be updated and reused. <span style="color:#808080;">{Paul}</span>

* <strong>Introduction:</strong>  there are now a number of tools that will fully support production of accessible websites.  While such an authoring tool may produce accessible content as configured (or even "out of the box" in some cases), specific implementations may prevent the creation of accessible content.  It's probably a good idea to mention that there are serious and sustained efforts by many companies to incorporate accessibility and within many different communities to develop default CMS themes that are accessible (Drupal, WordPress). The list 1-7 is also still valid, in my opinion. <span style="color:#808080;">{Paul}</span>

* <strong>Checklists for Authoring Tool Selection:</strong>  These don't feel like "checklists" to me, they feel more like a list of suggested questions someone who is selecting a new authoring tool should consider to help guide their selection process.  I suggest a short narrative here describing that ATAG and WCAG guidelines should be consulted in conjunction with these questions.<span style="color:#808080;">{Paul}</span>

* <strong>Evaluating software currently in use by an organization:</strong>  it might be a good idea to suggest ways for an organization to assess "just how bad is my current authoring software?"  This could be done internally via freely available assessment tools, or by one of the many competent consulting firms that specialize in this.<span style="color:#808080;">{Paul}</span>

* <strong>Selecting new or replacement software:</strong> In the United States, we have VPATs (Voluntary Product Accessibility Templates) that in theory explain how a vendor's software product meets section 508 checkpoints.  In the absence of such "identifying badges," how will individuals know how to assess each of these questions?  There must be a reputable list somewhere that identifies products, plug-ins, themes, and so on that meet minimum basic accessibility checkpoints.<span style="color:#808080;">{Paul}</span>

* <strong>Reviewing software procurement practices:</strong> Many governmental organizations require that software purchases adhere to basic accessibility laws.  However, accessibility is just one of many different purchasing criteria, and in many cases, the whole of accessibility is distilled down to a single checkbox, indicating that an "accessibility assessment" has been completed by someone in the organization.  Unfortunately, most organizations - even very large ones - do not have an individual with the responsibility (much less authority) to champion accessibility in the same way as cost, performance, interoperability, or some other criteria.<span style="color:#808080;">{Paul}</span>

* <strong>Questioning software vendors about product support:</strong> I think this section is perfect, wouldn't change a thing.<span style="color:#808080;">{Paul}</span>

* <strong>Working around Limitations of Existing Authoring Tools</strong>  I think parts of this section can be combined with the "Evaluating software currently in use by an organization" section above.  The results of an assessment can help determine what needs to be done to create accessible content.<span style="color:#808080;">{Paul}</span>

* <strong>Examples of strategies to work around limitations of existing authoring tools:</strong> Most of the examples cited are not strategies, but tactical solutions that rely on time-consuming manual labor.  There are many general updates needed in this section...references to "print-centric" authoring tools are stale, and many of the software examples are dated.  References to document conversion processes are still relevant; there are plenty of "how-to" tutorials available now.  Are missing DTDs still such a major issue that they need to be called out?<span style="color:#808080;">{Paul}</span>

* <strong>Product Reviews</strong> I really like this idea, but the reviewed authoring tools page is embarrassingly out of date and should probably be removed.<span style="color:#808080;">{Paul}</span>
==================


---------------------------------------------------------
Paul Schantz
Director, Web and Technology Services
Division of Student Affairs
California State University, Northridge
phone: 818.677.3839
e-mail: pschantz@csun.edu<mailto:pschantz@csun.edu>
twitter: @paulschantz
www.linkedin.com/in/paulschantz<http://www.linkedin.com/in/paulschantz>

www.csun.edu/sait
System notifications:  @CSUN_SAIT

Input | Intellection | Responsibility | Connectedness | Individualization | Accessibility