Open Source e-Learning
  • Login

Breadcrumb Navigation

Icon Wiki

Feature Wiki

Information about planned and released features

Tabs

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

...

Last edited: 09. Sep 2020, 15:46, Tödt, Alexandra [atoedt]


Search (Block)

Related Component/Module

Release Status

Development Status
-

Funded by
-

Testcases
-

Approval by Customer
-

Wiki Functions (Block)

Info

Recent Changes