Daniel Obadia - Integration New Media While AEM is designed to create and support accessible sites, there are several enhancements that help ensure that AEM adheres to all the requirements of a level AA accessible site. This session will look at a variety of enhancements that were made to AEM to help ensure compliance at this advanced level. Topics will include: • Creation of an accessibility dashboard that allows users to select fonts, font size, spacing and the option to choose from three different color palettes. • Improvements to the standard AEM form components for accessibility • Integration of a third-party Accessibility Checker for authors • Integration of an accessibility alert component to notify users when a page is not compliant • Additional accessibility enhancements made to templates and components.

1. CIRCUIT – An Adobe Developer Event
Presented by ICF Interactive
Making AEM Fit
Accessibility
Requirements
Daniel Obadia – Web developer
Integration New Media (INM)

2. • 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
Daniel.Obadia@INM.com
www.INM.com

4. 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

5. About INM
• Founded in 1989
• 200+ Clients across the globe.
• Strong Adobe AEM partner
• Diverse team with an emphasis on
technology and engineering practices.

6. Our Mission
Business
Objectives
User
Experience
Solid
Engineering

7. Almost
Everyone
here
Is
disabled
Or
will
be
at
some
6me…

8. • 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

9. 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…)

10. 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…

11. 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.

12. AEM & Accessibility
• Strong assumption that many elements for
accessibility were OOTB
• Many things needed modifications
• WCAG 2.0 “AAA” is not recommended
with AEM

13. AEM & Accessibility
h8p://adobe.ly/1LYS0ZT

14. 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

15. 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

16. 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

17. Achecker integration
• AEM
Page
informa6on
dropdown
customiza6on
• Java
sling
servlet
• OSGI
Config
node
• Achecker
local
install

18. 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

19. Ques6ons?

20. CIRCUIT – An Adobe Developer Event
Presented by ICF Interactive
Thank You!
Daniel Obadia – Daniel.Obadia@INM.com
www.INM.com