The company’s web developers are working hard to educate themselves about web accessibility, and they are actively attending workshops and investigating accessible web development practices. You see improved accessibility in the company’s websites, though there is still uncertainty about whether the sites comply with local accessibility requirements. You return to the accessibility auditing firm you are currently in contact with while you have been developing the company’s accessibility plan, and you ask for their assistance in auditing a number of new features that have been added to the main website. Ultimately though, you want to have an expert accessibility person on staff, who can provide accessibility audits on demand. In an ideal situation, an organization’s web developers would provide web accessibility audits. However, even with accessibility experience, it is wise to have a second pair of eyes review the work of the implementer. This task can be assigned to another developer or perhaps the Accessibility Champion. This is a typical practice in many development activities, and should be no different when accessibility is the subject. In the early stages of building accessibility knowledge into a company’s culture, however, the expertise may not exist in-house to provide effective quality assurance, so third parties may need to be brought in. Your senior web developer does have some experience with web accessibility, though he does not consider himself an expert. The other developers on staff are still new to the subject. As a result, there is not a sufficiently knowledgeable developer on staff to review the accessibility work of the senior member of the team. You decide that while your developers are building their accessibility expertise, you will bring in a third-party auditor, both to review and to train your developers. Accessibility reviews from an expert third-party auditor can act as a form of training. Typically, web accessibility reports will identify barriers, explain why particular barriers are a problem, and provide potential solutions to correct problems. They are typically written for a developer audience, so they are effective tools to educate developers. There will often be questions and feedback between the developer and the auditor, much like a student to teacher relationship. It may only take a few audit scenarios to bring developers to a point where they can do their own audits. Examples of accessibility auditing services:• WebSavvy Accessibility Consulting [https://websavvy.idrc.ocadu.ca/] • Deque Systems Inc. [https://www.deque.com/] • The Paciello Group [https://www.paciellogroup.com/] • Level Access [https://www.levelaccess.com/]. Another option to help ensure the accessibility of an organization’s web content, is to implement an accessibility monitoring system that will send alerts when potential problems are detected. There are a number of these systems available of varying cost and coverage, some of which include other quality assurance tests, like spell checking, finding broken links, testing text readability and even PDF testing. Though these tools can be helpful in catching issues, they should not be relied upon exclusively to identify all potential accessibility issues that may arise in an organization’s web content. Reviews by a human being should also be conducted on a regular basis. Reports could be shared through a knowledge base where all such reports and accessibility-related information can be stored. Here are a few examples of accessibility monitoring applications that might be used to supplement accessibility quality assurance efforts of an organization. Commercial systems: • User1st [https://www.user1st.com/] • Siteimprove [https://siteimprove.com/] • Compliance Sheriff [https://www.compliancesheriff.com/]Free open source: • Vamola (Italy) – now inactive, but a good base to build your own [https://regioneer.github.io/projects/vamola.html]. Document-accessibility auditing is relatively simple when compared with web accessibility auditing. Typically, a third party review of documents is not necessary, though there may be cases where complex documents, like forms, do require more than basic skills to make them accessible. For most documents, running the authoring software’s accessibility review tool is sufficient to pick up any potential problems that may exist in a document. Training to use these tools can often be completed in a few hours, followed by opportunities to use these new skills to develop expertise. It may be helpful to have other document authoring staff quickly examine accessibility for the author, as a second review to ensure the document is as accessible as it can be. Having staff review others’ work for accessibility can help strengthen accessibility awareness and maintain accessibility skills across a broader range of staff. If you have a copy editor or production editor on staff, who reviews grammar, word usage and spelling and so on, this person may be a good candidate to develop expertise in document accessibility testing - to combine accessibility testing with copy editing.