Suggested Accessibility Process

1 Guideline

1.1 Roles

1.1.1 Community Test Manager

• coordinates accessibility testing

1.1.2 Test Case Author for Accessibility 

• Prepares and organises Test Cases of the Accessibility Test Suite
• Supports Community Tester for Accessibility, improves cases upon feedback from Community Tester or Developer
• Analyses Accessibility Assessment Reports. Reviews Test Suite in the light of said report and makes changes accordingly. Supports Community in preparing bugs based on Accessibility Assessment Reports
• Has sound understanding of accessibility and can be consulted by developers on bugs. 

1.1.3 Community Tester for Accessibility 

• Carries out test cases of accessibility test suite in Beta phase 
• Uses of simple diagnostical browser extensions like WAVE or Lighthouse to automate a part of testing
• Provides feedback on quality and coverage of accessibility test suite to Test Case Author for Accessibility 
• Analyses External Beta Accessibility Assessment Reports. Prepares bugs based on report
• Has sound understanding of accessibility and can be consults by developers on bugs

1.1.4 Managing Director of ILIAS society

• Contracts external Beta Accessibility Assessment with dedicated agency 

1.1.5 Product Manager

• Ensures accessibility is aptly considered in feature requests in Jour Fixe

1.1.6 Maintainer

• develops new components and features in accordance with accessibility guidelines
• carries out the Accessibility Checklist on own projects and reviews own code with focus on accessibility
• Builds sound understanding of accessibility, contact Accessibility Mailing List to get better understanding of accessibility issues of projects, bugs or Guidelines

1.1.7 Developer

• develops new components and features in accordance with accessibility guidelines
• carries out the Accessibility Checklist on own projects and reviews own code with focus on accessibility
• Builds sound understanding of accessibility, contact Accessibility Mailing List to get better understanding of accessibility issues of projects, bugs or Guidelines

1.1.8 UI-Coordinator

• triages objectively testable accessibility bugs for UI-KS-elements
• checks if formal requirements are met and code is at the correct locus
• Builds sound understanding of accessibility, contact Accessibility Mailing List to get better understanding of accessibility issues of projects, bugs or Guidelines

1.1.9 Member of Accessibility Mailing List 

• supports maintainer with general and specific questions regarding feature requests and implementations
• works on processes and strategies to improve processes
• is part of the SIG Accessibility and take part in the discussions there
• Analyses Accessibility Assessment Reports. Reviews Test Suite in the light of said report and makes changes accordingly.
• Provides feedback on Feature requests before Jour Fixe.
• is encouraged to take part in Jour Fixe to answers questions on bugs and features.
• Carries out After-action-Review
• responsible for this document

1.1.10 Chair SIG Accessibility

• role requirements are desicribed in Rules of Procedure for Special Interest Groups 
• advocates accessibility to community i.e. ensures reports are prepared on DevConfs.
• organizes or initiates or delegates the fundraising

1.1.11 Accessibility Contractor 

• Is contracted to perform audits and run accessibility trainings for developers and community members
• is contracted to advise and consults on major UI Developments
• Accessibility contractors should be tendered and selected from BITV-Test-Prüfverband or similar. 

1.2 Community Tools

1.2.1 Guidelines

• The accessibility guidelines are verbatim quotes from WCAG guidelines. They remain unchanged. We accompany the verbatim guidelines with
  • specific rules in KS entries which interpret guidelines for UI-elements
  • Accessibility Checklist interprets guidelines to make them objectively testable wherever possible
  • We accept that there is ambivalence in the rules that are not objectively testable. We strive to shrink this ambivalence. 
• Accessibility guidelines are kept in synch with WCAG developments
• Access Guidelines refer to resources on specific accessibility issues for all consumers to look up and self-educate

1.2.2 Requirement Management Tool - Feature Wiki

• For Feature Requests a dedicated section "Accessibility" is to be filled out by the maintainer - very much like "Privacy".
  • Maintainer has to state if the feature implements a behaviour that is not covered either by an existing UI-Component or complies with accessibility guideline. If this is the case maintainer has to consult with the accessibility list
    • Accessibility list provides risk analysis of this specific feature in Feature Wiki  and recommends an accessible approach
  • If the maintainer is unsure about the accessibility issues of the feature, the maintainer may turn to Accessibility Mailing List
• It is to be completed before the article can be finally decided by Jour Fixe

1.2.3 Community Testing Tool - Testrail

• A test suite dedicated to Accessibility is available
• Test cases are well groomed, easy to carry out and understand
• Test cases refer to resource on specific accessibility issues for all consumers to look up and self-educate
• Test Cases are provided that use simple diagnostical browser extensions like lighthouse, HTML Validator or Wave browser extension
• All KS-Entries are tested for the prioritized issues and using automatic tools

1.2.4 Development Tools - suggested WAVE API

• Detects issues very early on and drives home the importance of accessibility during development.
• Reports are prepared with Continuous Integration and reported to Jour Fixe. 
• All developers are encouraged to make use of simple diagnostical browser extensions like lighthouse, HTML Validator or Wave browser extension

1.2.5 Bug Tracker - Mantis

• Bugs can be reported on automatically testable violations of guidelines. 
• Bugs can be reported on violations of accessibility rules listed in a KS entry.
  • If the KS rules themselves are wrong, the KS entry is to amended via the normal KS process. 
• Bugs can be reported against soft / non-objective parts of the accessibility guidelines. These require discussion and decisions. 
  • Accessibility Guidelines are to be amended / clarified to become more objective. Bugs are assigned to Accessibility List.

1.2.6 Jour Fixe - suggested Accessibility Status Report

• Maintainers can put forward their Accessibility issues that came up during implementation as "Development Issues". 

1.2.7 Accessibility Checklist

• Accessibility Checklist is documented as md-file along with the accessibility guidelines. 
• Maintainers use Accessibility Checklist to assess accessibility of their ongoing implementation projects. 

1.2.8 Accessibility Mailing List

• First POC for Maintainers
• Maintainers, writers of Feature wiki articles can turn themselves to Acessibility Mailing List to get their issues looked at. 

1.3 Web Accessibility Cycle

1.3.1 Contracted External Beta Accessibility Assessment - November

• Early in Beta phase a formative Accessibility Assessment is carried out by a registered auditor. 
• The Beta Accessibility Assessment strives to unearth as many accessibility issues as possible  using the 60 BITV test cases / WCAG success criteria.
• Fundraising and tendering are planned for well in advance. 
• ILIAS society provides test installation. 

1.3.2 Huge Project Identification Jour Fixe / Yearly Project

• During the Huge Project Identification Meeting we try to identify large UI heavy components to make sure accessibility issues are addressed early and continuously
• Huge UI heavy components may choose to contract external accessibility testing before merging

1.3.3 After-Action Review Accessibility - March 

• Yearly meeting open to all community members
• After publishing the stable release, the former season is analysed with respect to accessibility
• Draws up plan for upcoming season
• How well did our current guidelines hold water during this release?
• Maintains and reviews accessibility guidelines according to and based on new guidelines from the WCAG or other major developments outside the ILIAS Community
  • Triggers UI-Coordinators to review existing UI Components based on the above-mentioned changes, and to adapt of rules of individual components.
  • Triggers Test Case Author to adopt Test Suite. 
• Reviews processes and roles that manage accessibility 
• Responsible: Accessibility Mailing List

1.3.4 Feature Freeze - April

• Features for Accessibility Improvements are to be handed in on time. 
• Features for Accessibility Improvements are derived from the After-Action Review. 

1.3.5 KS Development

• KS entries adhere to accessibility guidelines
• KS entries comprise specific accessibility rules

1.3.6 Feature Development

• feature implementation must adhere to accessibility guidelines 
• maintainers carry out Accessibility Checklist during implementation

1.3.7 Community Testing - November

• In Beta Phase the new release is specifically tested with regard to accessibility. 

2 Status

• Effective from release: { not approved yet | x.y }
• Approved by Jour Fixe at: { link to Jour Fixe agenda }
  
• Implementation status: { implemented completely | partly implemented | needs implementation }
• Funding for streamlining existing features: { name of organisation }
• Implementation of guideline: { all developers | name of responsible developer }

3 Components that are not compliant with the Guideline

• …

4 Discussion

...