adobe experience manager - user group in ottawa

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

Making AEM Fit Accessibility Requirements June 7th, 2016

© 2016 INM – All rights reserved


•  AEM Certified Developer •  Passionate about AEM •  Great community behind AEM •  Strong emphasis on user/author

experience [email protected] www.INM.com


INM: Digital Engagement Platforms Specialists

•  27+ years of Successful Client Projects •  Clients Across the Globe •  Your Boutique Technology Partner •  Adobe Partners since 1999 (AEM: since 2011) •  Most certified AEM experts in Quebec •  Most successful AEM projects in Canada •  “AEM Specialized” Business Partner since May

2016 – less than 50 companies share this status


INM’s MISSION Business

Objectives

User Experience

Solid Engineering

Deliver the most inclusive experience to all users

Reliable, scalable, maintainable, interoperable, upgradeable tools

Economical to produce and maintain, Easy to learn and use, Never leads to redundant efforts...


Principles Lead to…

•  INM AEM Foundation: a set of templates and components made accessible By Design http://inm.com/foundation

•  INM AEM Accessibility Checker: Just-in-Time

Accessibility for Authors http://inm.com/accessibility-checker


Today’s Discussion •  Context (done)

•  Web Accessibility Legislation and Guidelines

•  Our Project

•  AEM & Accessibility

•  Accessibility Dashboard

•  Accessibility Checker Integration

•  Headaches worth pinpointing

•  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: •  For Federal and Provincial Governments projects

•  Other examples of Accessibility Legislation/Regulations:

•  US has their own guidelines: “ADA” and “Section 508” - WCAG 2.0 •  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. Some obligations as of January 1st, 2016. •  Private & Public sectors •  Quebec: SGQRI-008 – a variant

•  What does AODA mean for us? •  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? •  Ethically the right thing to do •  Reduces risk of legal action, negative image •  PR benefits, corporate social responsibility •  Overlaps other best practices in SEO, mobile web design, usability…


Our Project

•  Create a solid Foundation to build AEM projects on with strict adherence to AEM principles to ensure optimal performance and scaling

•  Accessibility was a key motivation – WCAG 2.0 Level AA / AODA •  We started with a strong assumption that many elements for accessibility

came OOTB with AEM. In reality a lot of customization was required


Project Goals

•  Layouts, templates, design, components needed to be compliant •  Accessibility Checker 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


Accessibility Dashboard


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) •  Accessibility Checker was integrated into the AEM authoring

environment to support author compliance


Accessibility Checker Integration

•  Hosted on AWS •  You install an AEM Package on Authoring Environment •  Authors get a “Check AA Compliancy” button for real-time validation

before publishing a page •  Available now as a Private Beta


Accessibility Checker Integration


Headaches worth pinpointing

•  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


Headaches worth pinpointing

•  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…

•  Many people start with a strong assumption that many elements for accessibility come OOTB with AEM. In reality a lot of customization was required

•  Projects built on INM AEM Foundation are WCAG 2.0 “AA”/AODA compliant

•  It was very helpful to have the Accessibility Checker integrated within the author instance


Stay in touch

[email protected] www.INM.com User Group Meetup Group – www.meetup.com/Adobe-Marketing-Cloud-Montreal-User-Group/