Making AEM Fit Accessibility Requirements

www.INM.com +1 514 871 1333 [email protected]

Making AEM Fit Accessibility Requirements November 12th 2015

© 2013 INM – All rights reserved


Today’s Discussion

•  Web Accessibility Legislation and Guidelines

•  Our Project

•  AEM & Accessibility

•  Accessibility Dashboard

•  AChecker Integration

•  Takeaways & Recommendations

•  Q&A


Almost

Everyone here Is disabled…

Or will be at some time…


Web Accessibility Legislation and Guidelines

•  Today’s focus is around Canadian standards: •  Primarily for Federal Government projects •  US has their own guidelines

•  Other examples of Accessibility Legislation/Regulations: •  Disability Discrimination Act 1992 - States that all Australian government websites must meet

WCAG requirements •  BS 8878:2010 Web accessibility. Code of practice - UK guidelines that dictate how to comply

with the UK Disability Discrimination Act 1995 •  UNE 139803 - Spanish accessibility guidelines that track very closely to WCAG standards


AODA & WCAG •  AODA : Accessibility for Ontarians with Disabilities Act

•  January 1st, 2025 •  Private & public sectors

•  What does AODA mean for us developers? •  Public & large organizations will need to have WCAG 2.0 “AA” compliant websites •  Perceivable: Alt text, Assistive technologies (JAWS, Voiceover), audio transcripts… •  Operable: Navigate with keyboard, eliminate blinking, eliminate redirects and other content

changes •  Understandable: Identify i18n sections, Identify page focus points, consistent functionality

across pages, video captions, clear definition of user inputs & error messages •  Robust: Supports plugins, scripts, applets and other current or future user agents, content

within them are accessible (PDF files and PowerPoint files…)


Sounds like a lot of work!

•  Is accessibility really valuable for a project? •  Reduces risk of legal action, negative image •  PR benefits, corporate social responsibility •  Overlaps other best practices in SEO, mobile web design,

usability…


Our Project

•  Website project for an Ontario Provincial government department. AEM was the chosen platform

•  Accessibility was a key motivation – WCAG 2.0 Level AA / AODA Thousands of content pages to upgrade/migrate and make accessible-friendly, by the internal team

•  We started with a strong assumption that many elements for accessibility came OOTB with AEM. In reality a lot of customization was required


What the client asked for

•  Layouts, templates, design, components that needed to be compliant

•  AChecker.ca must provide “0” errors •  Screen reader validation (Jaws & VoiceOver) •  Accessibility notice for rare cases •  Ability for site users to customize overall look (font,

contrast, size, character spacing)


Accessibility Dashboard

•  Choice of style is kept in browser cookie •  Cookie value is then assigned to HTML element •  Cookie value = CSS class •  Preview area for users








How did we approach the project?

•  To achieve the accessibility requirements, INM: •  Ensured that all components used by authors were compliant •  All templates included properties and options that authors

needed to fill out to comply •  AEM default components that were not compliant were hidden

from authors (i.e. the default table component) •  AChecker was integrated into the AEM authoring environment to

support author compliance


AChecker integration

•  AEM Page information dropdown customization •  Java sling servlet •  OSGI Config node •  AChecker local install






What are some of the things we had to change?

•  Tables – upgrade WYSIWYG plugin to add captions, summary attribute, scope attribute to associate header cells with data cells

•  Radio buttons/checkbox : Fieldset Legend was not available OOTB

•  Override LayoutHelper class to add “required” text beside labels as it was just a “*” for required fields


What are some of the things we had to change?

•  Aria attributes were not available OOTB on form components, Bootstrap Accessibility plugin helped

•  Text component generating <b> and <i> tags instead of <strong> and <em>, not handled well by screen readers

•  Integrate latest version of RECATPCHA from Google for it’s new simple action validation


In the end…

•  We started with a strong assumption that many elements for accessibility came OOTB with AEM. In reality a lot of customization was required

•  Client got what they asked for •  Website was WCAG 2.0 “AA”/AODA compliant •  It was very helpful to have AChecker integrated within

the author instance •  WCAG 2.0 “AAA” is not recommended with AEM



Stay in touch

[email protected] www.INM.com

Date post:	29-Jan-2018
Category:	Technology
Upload:	inm
View:	527 times
Download:	0 times

Making AEM Fit Accessibility Requirements

Technology