+ All Categories
Home > Technology > CIRCUIT 2015 - Making AEM Fit Accessibility Requirements

CIRCUIT 2015 - Making AEM Fit Accessibility Requirements

Date post: 19-Aug-2015
Category:
Upload: circuit
View: 52 times
Download: 7 times
Share this document with a friend
Popular Tags:
20
CIRCUIT – An Adobe Developer Event Presented by ICF Interactive Making AEM Fit Accessibility Requirements Daniel Obadia – Web developer Integration New Media (INM)
Transcript

CIRCUIT – An Adobe Developer Event Presented by ICF Interactive

Making AEM Fit Accessibility

Requirements Daniel Obadia – Web developer

Integration New Media (INM)

•  AEM 6.0 Certified Developer •  Deep knowledge of several popular

CMS’es •  Strong emphasis on user/author

experience •  Loves to stay current on emerging

technology and integration techniques [email protected]

www.INM.com

Agenda

•  About INM •  AODA/ADA/WCAG •  Our project •  AEM & Accessibility •  What did our client ask for? •  What did we have to change or add? •  How we approached the project •  Q&A

About INM

•  Founded in 1989 •  200+ Clients across the globe. •  Strong Adobe AEM partner •  Diverse team with an emphasis on

technology and engineering practices.

Our Mission

Business Objectives

User Experience

Solid Engineering

Almost  Everyone  here    Is  disabled  

Or  will  be  at  some  6me…  

•  The legislation that we're talking about today is around Canadian standards. But these are very much inline with the North American Standards, such as: •  Primarily for Federal Government projects •  http://accessibility.psu.edu/guidelines/section508

•  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

Web Accessibility Legislation and Guidelines

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 make their

websites compliant with WCAG 2.0 “AA” •  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.

•  Site has significant traffic volume during peak periods – every 3-4 years – minimal traffic during other periods.

•  Accessibility was a key motivation – WCAG 2.0 Level AA / AODA compliance

•  AEM was the chosen platform. •  Thousands of pages of content for the internal team to

upgrade/migrate and make accessible-friendly.

AEM & Accessibility

•  Strong assumption that many elements for accessibility were OOTB

•  Many things needed modifications •  WCAG 2.0 “AAA” is not recommended

with AEM

AEM & Accessibility

h8p://adobe.ly/1LYS0ZT  

Client asked for…

•  Layouts, templates, design, structure and content must be tested for Accessibility validation under AODA “AA” & WCAG 2.0 “AA” requirements •  achecker.ca must provide “0” errors

•  The site must be tested for screen reader validation using Jaws and VoiceOver

•  Include an accessibility notice •  The site’s users must have access to an

“Accessibility” link on a page where the user can customize the overall look, feel, contrast ratio and content font and size

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 in 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  informa6on  dropdown  customiza6on  •  Java  sling  servlet  

•  OSGI  Config  node  •  Achecker  local  install  

What are some of 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

•  Aria labels 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

Ques6ons?  

CIRCUIT – An Adobe Developer Event Presented by ICF Interactive

Thank You!

Daniel Obadia – [email protected]

www.INM.com


Recommended