Until now, SharePoint users did not have tools that would let them create Section 508 compliant web content prior to publishing, leaving them to deal with web accessibility as a post-publication issue. Deque, a Microsoft Gold certified developer, created the suite of add-ins, ribbon extensions, and Web Parts for SharePoint to solve this problem at its root cause. With the Deque solution at their fingertips, content creators can now engage in “preventive authoring”, which is the highest industry best practice for accessible web development activities and workflow management.

Non-compliant web content increases the risk of disability-related litigation before it is resolved. Deque’s SharePoint accessibility tools enable organizations to improve development processes so that non-compliant content is neither created nor published. As a result, organizations can eliminate time-consuming and costly compliance remediation activities, and development teams can focus their energies on creating additional value instead of fixing web accessibility problems.

“Enterprise computing is complicated. Adding a compliance remediation step after publishing web content only adds another layer of difficulty onto really complex workflows,” said Preety Kumar, CEO of Deque Systems, “With our new tools, SharePoint users can stop wondering if their content is accessible, they’ll just know. It’s like going from a rock and chisel to an iPad.”

The suite of Deque SharePoint accessibility tools are part of Worldspace Enterprise, Deque’s compliance validation solution for teams and organizations that produce large scale, dynamic web applications that must be universally available. For more information, please visit http://www.deque.com/products/deque-labs

Like all software however, we also received some feedback that was not so good – specifically we discovered some incompatibilities with the WAVE toolbar. Now some would say that we did this on purpose (and I wish we were that sly) because the first beta stopped WAVE from appearing in the toolbar and stopped it from working altogether – that is however not the case. So yesterday we released Worldspace FireEyes beta 2 which has a bunch of fixes including one that makes it compatible with all the other toolbars out there.

The next beta of Worldspace FireEyes will include some major new features and we’d like your input as to which features to include. Please participate in the beta 3 features poll.

List of Improvements in Beta 2

New Features and Improvements

• Keyboard shortcut (Alt+F12) to toggle Worldspace FireEyes.
• ‘Restore defaults’ feature: synchronize various options for a given project to their default states, found on the Settings tab.
• When defining a new project, domain(s) associated with that project will be added to the Firebug activation list.
• Improvements to status bar widget.
• User interface improvements related to filtering issues, changes, and events shown on the Current Document and Report tabs.

Bug Fixes

• Improve compatibility with other Firefox extensions, specifically ColorZilla, the Web Developer Toolbar, and the WAVE Toolbar (bugs #584, #585, #596)
• Worldspace FireEyes now supports multiple projects in a single browser window
• Remove Firefox zombie preferences associated with a Worldspace FireEyes project when that project is deleted (bug #567)
• Fix a problem on subsequent loads or reloads of a document, where previously discovered issues would not be highlighted (bug #575)

Accessibility Enhancements

• Eliminate flicker while performing color contrast analysis
• Current tab is now reported correctly to AT (bug #582)

The first beta is being put out there to see the reaction that the community has to the world’s first dynamic accessibility evaluator. Worldspace FireEyes includes features that work well with static sites as well as some features designed specifically to address the needs of JavaScript applications.

We really wanted to push the envelope on the usability side. We think that the accessibility community has been given short shrift up until now in this department. So even though some of our static functionality exists elsewhere, we wanted to make it much easier to use with Worldspace FireEyes. We hope we have achieved this and would love to get feedback from the accessibility community on the places we have hit the mark and the places where we still have some work to do.

We also wanted to push the envelope on the dynamic side. We have features that track all events in the browser and look for patterns that indicate accessibility issues. We can detect dragging of sliders and drag and drop operations and warn the developer to make sure those features are keyboard accessible. We track focus as it changes in the browser and (combined with aria attributes) raise issues or warnings when the correct behavior does not happen. Most importantly, we do not generate false positives – or at least we tried really hard. We’d love to get feedback from the dynamic application accessibility and the WAI-ARIA communities on how we did and what we can do to improve even more.

We also wanted to push the envelope on some of the more tedious analyses such as color contrast and reading order analysis and have added features to really speed up the evaluation of a page and determining why something is not right. We can detect the correct background even when an element’s background is not in the same HTML tree as it. We can detect the correct contrast – even when the background of an element is a graphic. These are things that the Juicy Studios tool cannot do. Check out the “Details” popup on the color contrast issues…we think its cool. We’d love to know what you think.

Finally, we wanted to support the way that developers and designers work. We think that making it easy, fun and even cool to create accessible content is the only way to ensure that it gets done. Thats why we integrated Worldspace FireEyes into the most widely used development tool – Firebug. We have also built in support for project life cycles to make it easy to do the right thing.

In all of these areas, there are bunches more features we want to add soon. This is why we released it as a beta. We’d love to get your feedback on what to add too, so get engaged and stay tuned.

There are a couple of difficult issues for developers of rich Internet applications with respect to content that the application changes on the fly. One of these relates specifically to being able to triage problems with content that appears for a short period of time and then disappears again. Examples of this include search suggestions and instant message communications.

This video shows how FireEyes and Firebug can be used to identify these issues while using the application and then triage and fix these issues.