Accessibility Roadmap for IEEE Sites

The following guideline—adapted from a deliverable by IEEE accessibility partner Deque Systems—provides IEEE site managers with a starting point for integrating accessibility into your work.

The roadmap may be fully implemented by the site team (depending on resources and skill sets) or through collaboration with a vendor or another site team. It should not be considered a comprehensive or perfectly linear list of steps and should be modified to the needs of your site/project.

Understand Accessibility Requirements

Before planning for the incorporation of accessibility into your site and programs, it is important to understand the IEEE requirements related to accessibility, as well as related industry governance. The following documents should be reviewed and understood.

Assess Environment, Commitment and Resources

Understanding the business context and level of commitment in order to address any impediments is critical to the long-term success of your initiative.

To gain this knowledge, conduct interviews with upper management, project management, developers, designers, quality assurance testers, configuration managers, business users, and content contributors. (See possible considerations below.)

Category Considerations
Commitment Does the site leadership team support a strategy that will make accessibility a standard component of all projects? Will necessary financial and human resources be allocated?
Expertise Are necessary team members familiar with IEEE and industry standards related to accessibility? What is their level of knowledge or experience? Are there any experts?
Governance Are the accessibility roles, responsibilities, and processes clear?
Training Do team members understand the technical solutions for writing and testing web code and content that would meet the WCAG 2.0 standard?
Checklists Has the team implemented a checklist to ensure standards compliance?
Quality Assurance Does the QA team have the required knowledge and tools to confidently conduct WCAG 2.0 testing?
Defect Reporting Is there a system in place to track defects?

Depending on the outcome, it may be necessary at this stage to establish an accessibility champion and/or committee whose purpose may include:

  • Reinforcing the commitment to accessibility
  • Providing influence and insight into top-level site management
  • Helping to secure resources and drive alignment
  • Providing feedback or buy-in on key accessibility decisions and plans

Create Objectives and Project Plan

Objectives help keep your initiative focused and ensure all stakeholders have the same vision for success.

Possible accessibility objectives:

  • Meet WCAG 2.0 Level A accessibility standards by <date> (required)
  • Meet WCAG 2.0 Level AA accessibility standards by <date>
  • Create a highly usable, engaging experience for site visitors with disabilities
  • Serve as a model of accessible web strategies and practices

Once objectives are created, a project plan is needed to outline the required steps as well as to ensure that resources are available when needed. This roadmap can serve as a framework for that plan.

Establish Training, Support and Communications Programs

Training and support are essential to a successful launch, the sustainability of your accessibility initiative, and the engagement of your team. Various resources are available online at no cost, or team members may be given the opportunity to register for university programs or conferences such as:

Email the Digital & Creative Innovations Team at if you decide to attend one of these conferences or if you are looking for other accessibility resources.

When developing your accessibility communication plan it is important to include the following steps:

  • Determine who is best suited to write accessibility communications.
  • Identify key audience groups that will be affected by the new accessibility policy and processes.
  • Conduct an accessibility awareness campaign so your team understands the value and importance of this initiative as well as the resources and support available to help them.

Establish Processes and Guidelines

Developing and implementing processes and guidelines will be a key component of your project plan and will help ensure the hard work done to complete the compliance project plan is not soon undone.

Although document needs will depend on the team and project, generally at least one checklist, process, or guideline is needed for each role (business analyst, editor/contributor, developer, QA, etc.) or project stage (requirements, content creation, development, testing). Usage of existing online tools from credible sources is highly encouraged. Some processes may also be extrapolated from this guideline (see steps 7, 8, 9, 10, and 11).

Assign Roles and Responsibities

Processes are only as effective as the individuals assigned to execute them, so verify that there is clarity among the team about who will perform which responsibilities.

During this process, consider the following roles. These roles may be assigned to a single site accessibility coordinator (which may be the webmaster for smaller sites) or distributed across multiple team members.

  • Communicates accessibility policy within the team and promotes awareness
  • Identifies accessibility training needs and recommends resources
  • Provides documentation including testing plans and workflows
  • Keeps up to date on the evolving accessibility standards and best practices
  • Monitors compliance (monthly) to accessibility policy
  • Reports on accessibility implementation plans and progress
  • Remediates accessibility issues according to best practices and conformance criteria
  • Maintains documentation on all exceptions and reviews regularly for progress

Equip Team with Tools and Training

Using the training program established earlier in the project, prepare team members for the roles they have agreed to serve by providing role-based accessibility training to web developers, designers, quality assurance testers, and content contributors. See suggested curriculum below.

Developer Designer QA Tester Content Contributor
IEEE Accessibility Requirements required training required training required training required training
Accessibility Fundamentals required training required training required training required training
Accessible HTML/CSS Basics for Developers required training required training
Accessible HTML for Content Contributors required training
WCAG 2.0 Accessibility as-needed training
Flash Accessibility as-needed training
Accessible PDFs as-needed training
Desktop Testing Tools required resource required resource required resource

Web developers, designers, quality assurance testers, and content contributors should also be set up and trained to use page-by-page testing tools as well as a screen reader. The IEEE Digital & Creative Innovations Team has a screen reader available for use in the IEEE UX Lab at the IEEE headquarters. Contact the IEEE Digital & Creative Innovations Team for more information or to schedule a session.

Incorporate Accessibility into Requirements

Whether site work will be done by the project team or in collaboration with an outside vendor, it is important that the compliance expectations for accessibility have been documented within the project requirements.

During the requirements stage, the QA team should also be asked to provide standard test cases to ensure that there is a measure for success associated with all requirements.

Develop Accessible Content

The content development process may include the following:

  1. Accessibility training, documentation, and checklists are available for content contributors and developers.
  2. Application Programming Interface call is added to accessibility testing tool in content management system (at the point where contributors or developers have just submitted content for review by the QA team).
  3. Content contributors or developers remediate issues that can be tested automatically.
  4. QA team conducts manual testing and provides list of remaining issues to content contributor or developer to be resolved.
  5. Contributor/developer makes necessary changes and submits content to QA.
  6. QA team conducts final manual review confirming pages are accessible.
  7. Accessible content is deployed in production.
  8. Compliance is monitored.

QA and Testing

Testing for accessibility should encompass the following:

  • Accessibility verification of third-party content/functionality before purchase
  • Distributed unit tests for accessibility
  • Centralized automated tests for accessibility
  • Manual testing (consider using the WebAim WCAG 2.0 Checklist)
  • Periodic expert accessibility/usability evaluation with assistive technology*
  • Accessibility testing with people with disabilities*
    Refer to Shawn Henry’s online book “Just Ask:  Integrating Accessibility Throughout Design”

*Expert reviews and usability testing should be planned in conjunction with releases of significant new functionality or redesigns.

Regular Monitoring and Reporting

The team accessibility coordinator (or other assignee) will monitor the state of web accessibility. This may be accomplished by setting up a testing tool to run automated scans of the website on a monthly basis. The monthly scans should be distributed to the respective page/content owners and remediated according to the established process.

To be as effective and efficient as possible, teams should also integrate automated accessibility testing via API calls into the web development, template creation, and content creation stages, wherever possible. This will create a proactive process that incorporates accessibility testing into every phase of web development.

At a high level, site monitoring may include the following steps:

  1. Conduct an automated accessibility review of 25 recently developed representative pages against the WCAG 2.0 standard.
  2. A manual review should also be conducted to catch issues that cannot be tested automatically.
  3. Identity the total number of issues as well as the priority pages with the most violations.

Regular Remediation and Retesting of Issues

The high-level process for accessibility remediation is as follows:

  1. Prioritize: Determine in which order you will address accessibility errors.
    - Global template issues should be addressed first.
    - High priority pages should be addressed next.
    - Remaining page issues should be prioritized and addressed as possible.
  2. Assign: Identify an internal or consultant accessibility developer and expert to answer questions and advise developers and QA team (if needed).
  3. Test: Developers run FireEyes on each page/template to be remediated. Developers also review automated and manual accessibility reports (if available).
  4. Remediate: Developers resolve issues they already know how to fix. Developers request QA team review.
  5. QA: QA team conducts automated and manual testing and provides list of any remaining issues.
  6. Remediate: Developers make necessary changes and submit template to QA team for final review.
  7. Retest/approval: QA team conducts final automated/manual review confirming pages are accessible.
  8. Publish: Accessible pages/templates are deployed in production.
  9. Repeat: The above process is repeated until all pages/templates have been remediated.
  10. Monitor: Monitor compliance to ensure that remediated pages stay accessible.