Anthology Accessibility Statement – Encompass Support Center

Anthology Web Accessibility Commitment Statement

Anthology recognizes the importance of inclusiveness within a society, where inclusiveness means the ability for all to be engaged, to be involved, and to give back. This would not be possible without technology that is accessible to all parties within a community. As an organization, we are investing in web accessibility and making it a core focus in the following ways:

• Providing audience specific online and instructor-lead training for Anthology associates so that they are proficient in how their role impacts web accessibility on their respective domains
• Engaging with third party consultants to audit our compliance status and receive guidance on proper remediation methods
• Establishing a working group of clients with a heightened interest or experience in accessibility as it relates to digital content and applications, for the purpose of providing input, feedback, and guidance about Anthology’s accessibility efforts
• Engage with members of the Kansas City community with accessibility needs in order to gain valuable perspective and to give back
• Training, design, and professional services include web accessibility as a specific focus during client engagements
• Providing thought leadership to clients around the importance of web accessibility, and how Anthology engagement data shows that as an industry, advancement is acutely sensitive to lapses in accessible experiences.

Through these efforts Anthology strives to continually advance our ability to provide accessible technology. Upon request, Anthology is happy to provide our voluntary product accessibility template (VPAT) that conveys the compliance status of Anthology software.

If you have any questions or comments about the accessibility of our website or our products, please contact us at info@imodules.com.

Internal Compliance Practices

Anthology Development Team

There are numerous web accessibility checks built into our standard development processes to ensure that going forward, all code changes for existing as well as greenfield components are reviewed for their compliance to the WCAG 2.0 level AA standard.

Product and Feature Inception

Development related compliance efforts start early on in the development process during the inception phase. During this time, the Anthology’s product owner reviews with internal and external stakeholders the user problem at hand and, if known, the hypothesized technology solution to address the problem. It is during this phase that initial discussions around accessibility take place:

• What is the nature of the interaction that will take place with the involved component? What are the workflows, inputs, etc.?
• What type of design customizations are needed from client to client to meet their business need? Could customizations have an impact on accessibility?
• What implications does admin use of the component have on usability? Could an admin use the component or create content that would make the component inaccessible?

Feature Development

After initial concept development and requirements gathering has been completed, coding work by Anthology developers commences. This is time which the second development related accessibility check is performed. Before a developer can change the status of their work of delivered for hand off to quality assurance, they must perform an accessibility review of the involved components by utilizing one of the programmatic WCAG evaluation tools, and through keyboard only navigation. WCAG checks by the developer ensure that accessibility under the most common configurations are achieved.

If the development work directly relates to remediating an accessibility issue, the developers also perform validation using NVDA and Firefox.

Quality Assurance

Once corresponding code changes for a new enhancement or defect correction have been completed, it moves to the Anthology Quality Assurance (QA) team where a battery of automated and manual testing is performed. Web accessibility testing efforts performed by the QA team differ from developer related efforts in that the QA engineer will perform programmatic testing under a wider range of potential configurations that could be in use at a client site.

If the development work directly relates to remediating an accessibility issue, the quality assurance engineers also perform validation using VoiceOver and Safari. This way our processes provide coverage for more than one assistive technology and browser combination.

User Testing and Observation

Anthology has developed a network of resources to assist its development team with achieving real world validation of its accessibility related work. This would include engaging with individuals in the Kansas City community that have various types of disabilities that could impact their computer use and digital engagement. We involve these partners in validating the work that we’ve done from an accessibility standpoint, as well as incorporate their perspective in our product inception and planning process before actual coding work takes place.

Anthology Design Team

Custom Design Concept Development

While designing in Sketch, Anthology designers use the Color Analyzer plugin (https://github.com/getflourish/Sketch-Color-Contrast-Analyser) that checks the color contrast between 2 layers in the working document to make sure they meet WCAG AA contrast requirements. This will ensure that text has enough contrast from its background to be legible and accessible.

Custom Design Build

Anthology front-end developers start from an Encompass boilerplate that utilizes Grunt processes to generate site template files from HTML, LESS and JavaScript assets. Once these template files are loaded on the client’s website (or sub-community), the Project Manager will assign an Accessibility Quality Assurance (QA) task.

The Accessibility QA Task will give the developer and reviewer time to run the new templates through the the Wave tool from WebAim and HTML_Codesniffer from Squizlabs accessibility checkers to ensure that the templates meet WCAG AA standards of compliance for functionality (keyboard navigation, ARIA labelling, etc.) and structure (proper header layouts, alt tag attributes on global images, etc.). During this QA we will also test the keyboard navigation.

Builds from Match Design

Match designs are concepts created by the client with the HTML, CSS, and JavaScript generated by Anthology. The build process is similar to one starting from an in-house design, but without the color contrast checks. If any issues are found, they will be reviewed with the client before the Anthology front-end developer makes the agreed upon changes (the number of issues will be unique per template design).

Builds from Match Code

Builds from match codes mean the design and build is being matched by the HTML, CSS, and JavaScript, or a live site URL that are provided by the client. Anthology will take the code from the client as it is presented and insert these assets into the Encompass boilerplate to the best of our ability. If the template is not accessible upon delivery to Anthology, due to color or functionality issues, Anthology will not correct these issues (though if these fixes are requested by the client, additional time/services can be purchased to make these changes).

Third Party Consulting and Training

In the summer of 2017 Anthology contracted with the web accessibility consulting firm Microassist to perform a web accessibility audit of the front-end of the Encompass platform. As part of that audit, Microassist provided Anthology with a comprehensive report of Encompass’ accessibility to various assistive technologies based on the WCAG 2.0 level AA standard, and recommended remediation steps. Anthology has continued to engage with Microassist on an as needed basis to verify that development and design changes to items that have been flagged as out of compliance have been appropriately addressed before being released to client production environments.

In addition to contracting with third party consulting firm Microassist to identify gaps in Encompass web accessibility, Anthology is in the process of contracting with the non-profit accessibility firm WebAim to provide comprehensive two day instructor led training. The following Anthology roles will participate in some or all of the in person training:

• Software Engineer
• Software Quality Assurance Engineer
• Product Owner
• Front End Web Developer
• Web Designer
• Application Support Engineer
• Product Trainer
• Professional Services Consultant

The two day training will cover basic and advanced web accessibility topics, to include:

• Principles of Web Accessibility
• Web accessibility guidelines and laws – Section 508, WCAG 2.0, ADA, etc.
• How users with disabilities access and use the web
• HTML
• JavaScript, ARIA, and HTML5
• CSS
• Acrobat and PDF
• Microsoft PowerPoint and Word
• Captioning
• Evaluating site accessibility
• Using screen readers and other assistive technologies
• Policy creation and implementation
• System change for accessibility

Other Testing and Consulting Considerations

In addition to standard practices outlined above, the Anthology Research and Development team has also developed relationships with individuals within the Kansas City community with accessibility related needs. In addition to providing context and perspective that are invaluable to the development process, these partners also provide additional validation of accessibility related changes. This real world validation of our changes is a critical building block towards our goal of making our software accessible.

Product Usage Information for Users with Disabilities

Accessibility Features

• User experiences respond to their adjustments font size for ease of viewing
• Ability to embedded media within content support alternative text
• Ability to provide alternative text to time based media
• Ability to navigate and interact using keyboard only for most components
• Skip to Main Content links
• Landmark tagging for ease of navigation

Critical Accessibility Gaps

• Standard Image Rotator module does not support alternative text, and does allow for play/pause controls
• Radio groups on giving forms do not receive focus within the tab order
• Form field labels and alternative text for less predominant engagement modules are not supported. This would include Networking Groups, Member Photos, and Classifieds
• Field specific form errors do not list the error adjacent to the invalid fields, and invalid fields do not have any other visual queues indicating remediation is needed