The Process

We can help you to make your Web application or software product compliant with 508 and/or WAI accessibility requirements. Our process of retrofitting and redesigning is as following:

1. Discussion and Cost Estimate.

   After the initial contact, consultation and preliminary cost estimate that we provide free of charge, a Discussion stage is conducted. This stage focuses on discussion with the customer to ensure a clear understanding of what is needed and what is required. The environment, existing hardware, software, and other factors, are considered. A probe compliance audit and retrofitting work is run to estimate the exact time and cost for the whole system. After that we come up with a contract, a fixed total cost and a guaranteed project schedule.

2. Audit.

   We perform a careful analysis of your application to check for accessibility compliance and generate a complete list of deviations by type and location. Audit greatly depends on the type of your application. Usually, we need to analyze your project architecture: libraries, client-side code, other parts of source code. As a rule, we install your application and check it with special tools or check it directly on the Web.

3. Automatic checking and retrofitting.

   Using our proprietary Direct Source™ technology we find and fix many of accessibility violations automatically. This technology cuts retrofitting time and cost significantly. Then the resulting application is checked and validated by many other different tools and violations found are further fixed.

4. Manual review.

   Manual review is the most important part of retrofitting. No matter how complicated automatic tools for checking accessibility compliance are, the final results depend on human judgment. A good example for this is HTML tables. Tables can be nested, used to control layout, or be dynamically populated by data from databases. Automatic tools cannot determine the purpose of a table and decide whether it should be fixed in accordance with accessibility requirements (summary attribute in this case) or not. There are many other items that should be verified manually. See below a list of some accessibility deviations that should be verified and fixed manually.

5. Testing.

   A retrofitted application is tested by our Testing Laboratory, sometimes also by customers' staff, to verify that no new bugs are introduced and that all violations are fixed. As a positive side effect of this process, a general re-testing of your application is performed, problems found are reported and fixed, if approved by the customer, by our experienced designers and programmers.

6. Delivery and Technology Transfer.

   Retrofitted and tested application is delivered. Customer's IT staff is trained. We also provide our Direct Source™ software to all customers for whom we do retrofitting. This ensures that new applications developed by your staff are 508/WAI compliant.

Based on this process we guarantee delivery of a quality product in time and for affordable price.

Some Accessibility Deviations to be fixed in Web applications

• There should be a text equivalent for every non-textual element (i.e. images).
• If any information is conveyed with color, it also should be available without color, via text.
• There should be a way to skip repetitive navigation links (menus).
• There should not be any abbreviations or acronyms that can create nonsensical sounds when read by a screen reader application.
• Links that point to a JavaScript should have meaningful titles
• HTML controls like radio buttons, edit boxes, list boxes and check boxes should have corresponding labels and correct navigation.
• Tables used to display structured data should have correct labels for column and row headers and a meaningful summary attribute.
• And many others