Lectorra + 508 + JAWS = Disapointment

Tanja wrote:

Andrew,I will attempt to address your concerns. Thanks to CDC_Joe for his responses. We have worked with him regularly to help him create 508 compliant content.- buttons being read as visited when they aren'tWe are aware of this issue and are working to resolve itGood, but that doesn't help my current users.- buttons (and images with onclick actions) not reacting to the Enter keyThis is a JAWS bug, and is out of our control. Please see http://community.trivantis.com/forum_posts.asp?TID=3770&PN=1 for more information. Why is it that I can create a CSS-based button that can respond to/call javascript that does work correctly in Jaws? Given that Lectora buttons are read as visited, when they aren't, I'd be more inclined to think the error was not with Jaws.- no real way to have a button which when clicked on resizes all the textYes, this is true. However, there is no specific requirement within Section 508: 1194.22 Web-based intranet and internet information and applications, that requires this."No specific requirement" does not mean it is not commonly expected. Not being able to resize text is a clear accessibility/usability fault.- no way to add access keysLectora supports the creation of keystroke actions. As Joe pointed out, JAWS automatically disables these keystroke actions, however, JAWS can be configured to accept them by:1) Start JAWS2) Open Internet Explorer3) Hit INSERT+6 This should open the IE.JCS file.4) Click "Set Options"5) Select "Keyboard Options"6) Under "Navigation Quick Keys" change it from "On" to "Off"7) Save and close.- rudimentary table supportYes, this is true. We can only support very basic tables with a single header row. Once you have created a table in Lectora, highlight the row to be labeled as the header row, right click, select table, select header row. This will satisfy 1194.22(g). However, we cannot currently support 1194.22(h). But, with the use of an external HTML object of type "Other", you can manually write the html for more complex tables, and place it on the page. External HTML object of type other are simply published to the page within the page content, inside of blocks. Any free form HTML can be added in this way.Yes it does work but I have found it neither intuitive in its application or predictable in outcome.- no way to add HTML "accessibility" tags to elementsYou are correct, we do not support tags such as acronym, scope, etc.- focus not being given to the actual window content without users having to tab past IE's chromeThis simple limitation is a biggie for our users.- no external stylesheets that users can replace with their ownYes, this is true. The majority of our users have no desire or need to edit or replace style sheets. The lack of style sheets does not affect the ability to produce 508-compliant content.But you have not provided style sheets so how can you say how many people have a desire for them? It is common for my users to use add-ons like greasemonkey specifically to manipulate style sheets to their requirements.- Lectora inexplicable use of fixed font sizesLectora is designed as a WYSIWYG application. We render the font to the size chosen. There is no 508 requirement for web-based content to be able to resize text. I am aware that this is a requirement within other sections of 508, but it does not apply to web-based intranet and internet information and applications: Section 1194.22. If you are using Lectora to create actual .exe applications, and are subject to the requirements set forth in Section 1194.21 for Software applications and operating systems, then yes this would violate requirement (f).I'm unsure what accessible products you use which do not allow users to resize text but a fixed layout is reminiscent of the old CD Rom days and not something that should be part of the Web today.- having to jump through hoops to add "skip to content" functionalityThere really aren't a lot of "hoops" to jump through here. We have a single action - Go To, Current Page, with the ability to select a Scroll To point that can easily be defined as a "Skip to Main Content" link. This was a new feature added in 2007 to support 508 compliance. On a simple page things can work but on a complex page the task is not as straightforward as you make out.- generally, only being able to define a tabbing sequence by the actual relative location of the iconsThe tabbing sequence, as well as the order that a screen reader will read information on the page is defined entirely by the order of items in the left hand pane. Please see the additional post: http://community.trivantis.com/forum_posts.asp?TID=3274&PN=1 I know how to get a tabbing sequence to work. I'm actually referring to the amount of effort it takes when you've forced to go outside the order of the items in the left hand pane. Everything cannot always be reduced to a linear arrangement of icons.- how HTML published pages get a title (in the browser's title bar) that matches the actual file name rather than what was set for the project.Yes, I suppose this is an inconvenience. We render page names in the following manner: chapter_name_section_name_page_name.html Perhaps this is something we should reconsider.No it's not an inconvenience its a usability error. Why would a user care if its a001_stage_1_1._summary.html or a001_stage_5_5._scenario.html?I certainly understand some of your frustrations. However, many of the points you made do not actually affect Lectora's ability to create 508-compliant content. For example, you are correct, we do not support the "longdesc" tag for non-textual elements. However, we do support alt tags, and we do allow the creation of text blocks that can be used as captions for the images, or that can be placed under the images, and still read by a screen reader.Strictly speaking, whether or not content we produce is 508 compliant is neither here nor there. What does concern us is that our users who rely on assistive technologies cannot be given content which is usable for them (no matter how much we tweak lectora or the javascript lectora produces).There are some definite limitations. We cannot support keyboard functionality for our menu object, drag and drop or matching questions. However, if you are capable of writing the appropriate html code for creating accessible equivalents, then we do support the addition of your code.So how does lectora track a custom drag and drop question I might build? Do I have to deconstruct a lectora question and try to fit the tracking code to my question?I hope you will reconsider your opinions regarding Lectora. We have made many improvements to the product with 508 in mind. While there may still be some changes necessary for a more user-friendly experience, I firmly believe that we are not doing anything that blatantly violates 508.My initial concern was that we are unable to build content with lectora which satisfies the users we have that rely on assistive technologies. Nothing, so far, has changed that.Andrew Poulos