1

PRODUCING ACCESSIBLE SITES AND APPLICATIONS WITH AEMKiran Kaja | Accessibility Program Manager

2

WHAT IS ACCESSIBIL ITY?

Accessibility involves two key issues: How users with disabilities access electronic information How content designers, developers, and authors produce content that

functions with assistive devices used by individuals with disabilities. Accessibility is not a feature, it’s about procedures, processes, and

techniques

3

THE IMPORTANCE OF BEST PRACTICES

There is NO Accessibility Button – Accessible Content Creation is a Process NOT a Feature

Achieving Accessibility Requires Human Testing in addition to Automated Checking

Checking Can Only Detect for the Presence or Lack of Required Items Cannot Check if an Item is Correct or Appropriate

Accessibility is NOT a Feature, it’s a Result

4

THE ACCESSIBIL ITY BUSINESS CASE

• Government organizations are mandated to provide services to all citizens regardless of their disabilities.• Section 255 & 508, Americans with Disabilities Act (ADA, CVAA & State legislation• Higher Education & financial organisations have obligations under ADA• Universal access to services

• Other organizations comply voluntarily or as a result of legal action.• Landmark legal cases• Self-service movement • Corporate social responsibility• Positive press

5

GLOBAL ACCESSIBIL ITY STANDARDS IN 2006

Blue = Standards in effect

6

GLOBAL ACCESSIBIL ITY STANDARDS IN 2013

Blue = Standards in effect or policy in developmentRed = No standards

7

ACCESSIBIL ITY STANDARDS ARE ALL ABOUT END-USERS

End users have various disabilities. Sensory – blindness, low-vision, color-deficient vision, deafness, hard-of-

hearing, photo-sensitive seizures. Physical – various disabilities that result in varying degrees of dependence

on the keyboard interface. Cognitive – users who perceive and process information differently or with

greater difficulty. Very diverse range of user needs within this group. Many supports for blind users also benefit users in this group.

Users may have multiple disabilities (e.g. a deaf-blind user)

8

SCREEN READER DEMO

Demonstration: PSU Libraries home page with a screen reader.

9

SCREEN READER DEMO

10

WHERE YOU PROBABLY ARE RIGHT NOW

• You have a zillion documents• That aren’t actually documents, but a bunch of fragments thrown together• That 10 or 100 or 1000 or 10000 people can edit• Of which you’re one of 3 who know what they’re doing

• You have a CMS• Which came with templates you threw away• Probably developed by a consulting firm• And you don’t know what they did

• You have an accessibility problem• And somebody probably told your CIO their tool can solve it

11

• Look at your top pages on your top sites• Fix the most popular, most broken content• Solve template problems first• Minimize errors entering the system• Train your users

• …just a little

• Establish standards for• Design• Scripting

• Give yourself some room• Always focus on people

WHAT TO DO

12

• A set of technology agnostic Accessibility guidelines developed by W3Chttp://www.w3.org/TR/WCAG/

• Supported by non-normative documents• Understanding WCAG 2.0http://www.w3.org/TR/UNDERSTANDING-WCAG20/• Techniques for WCAG 2.0http://www.w3.org/TR/WCAG20-TECHS/

• 3 levels of conformance: Level A, Level AA & Level AAA• Level AA is realistic & widely used/accepted• WCAG2 being used as basis of legislation• Latest Section 508 updated draft in the US, Canada, Australia, EU,

etc

WEB CONTENT ACCESSIBIL ITY GUIDELINES (WCAG) 2.0

13

When using software and web sites, users need equivalent and predictable access to the interface, usually without relying on a mouse. 1. All tasks must be keyboard accessible, even if every method to accomplish

a task is not.Whenever possible keyboard access should match OS conventions.

2. Complex interfaces need to provide means to easily move around, without learning or performing multiple additional keystrokes.

3. Clear indication of focus location.4. Some users rely on speech access which has similar dependencies on

accessibility API information.

WHAT DO USERS WITH PHYSICAL DISABILITIES NEED?

14

When using software and web sites, blind users need information about the user interface – both about where they are and clues and tools to access the rest of the interface.All requirements for keyboard users apply for blind users1. Images need equivalent text2. Controls need labels that clearly define purpose3. Controls need to be correctly identified by role, with accurate state and

value information provided4. Relationships present within the content or application needs to be clear5. Correct reading order6. Language needs to be correctly identified.

WHAT DO BLIND USERS NEED?

15

When using software and web sites, low-vision users need to be able to view information in larger sizes.As a user’s visual acuity decreases:

More reliant on supports offered for blind usersLess likely to be able to effectively use the mouse

1. The focus needs to be clearly visible and programmatically locatable. 2. Text needs to be resizable.

WHAT DO LOW-VISION USERS NEED?

16

When using software and web sites, users with color deficits need high-contrast information and ideally the ability to modify the interface for further enhancements.1. Support for OS high-contrast modes2. Sufficient default color contrast (4.5:1) for all colored content

1. Text2. Focus caret3. Controls

3. Instructions that don’t rely on color (e.g. click the red button)

WHAT DO COLOR-DEFICIENT USERS NEED?

17

When using software and web sites, deaf users need text in place of audio.1. Closed captions for audio within video.2. Transcript for audio not synchronized with video or other content.3. Visual cues for audio alerts.

WHAT DO DEAF AND HARD-OF-HEARING USERS NEED?

18

Many different types of cognitive disabilities, which makes defining specific criteria very difficult.Clear, straightforward layouts and form design always a good practice.Some users will utilize assistive technologies which speak content and depend on accessibility API information.

WHAT DO USERS WITH COGNITIVE DISABILITIES NEED?

19

Rich Text Editor• Install & configure the paraformat plugin

to enable formatting options.• H1 through H6, lists, paragraphs, etc• Also add any block level semantic

elements that are not available by default.

• Enables administrators to specify additional HTML tags/attributes that can be used by content authors

PREREQUISITES: ADMINISTRATORS

20

• Decide on the formats styles that content authors can use: paragraph, h1, h2, etc

• Then specify the paragraph formats available in drop-down list of RTE• Formats can be added as nodes under the RTEPlugins/paraformat node

PREREQUISITES: ADMINISTRATORS

21

• Install the “Enable All RTE Features” Package• Provides a default set of formats and styles that can be further configured• Also adds a source edit mode for modifying resulting HTML• Download the package from the support site:

http://dev.day.com/docs/en/cq/current/administering/package_manager.html#Package%20Share

PREREQUISITES: ADMINISTRATORS

22

• Provide meaningful alt text for static graphics & images used as interactive components

• Image component dialog box > Advanced image properties tab > alt text

• If the image is decorative, use a space character in the alt text field to inform screen readers to ignore the image

• For complex images such as pie charts:• Provide a short explanation in alt text• Provide more detailed information in description field

PROVIDING TEXT ALTERNATIVES

23

• Advanced Image Properties dialog

PROVIDING TEXT ALTERNATIVES

24

• Use appropriate structural element for your page content in the Rich TextEditor

• <p> for paragraphs, <ul> or <ol> for lists, etc

• <strong> or <em> for bold and emphasised text

• Use format menu in RTE to pick correct structural element

APPROPRIATE STRUCTURAL ELEMENTS

25

• Create structure to your web pages by adding section headings• If RTE Features Package is installed, H1, H2 & H3 are already available (Refer

to Slide 20)• Additional heading levels (H4 through H6 can be configured by administrators

(Refer to Slide 20)• Correctly nested headings help screen reader users navigate content easily• Do not use headings to provide simple emphasis, use <strong> or <em>

USING HEADINGS

26

• All 3 HTML list types are supported:• Ordered, unordered & definition lists • Select the list type from the format menu• Using lists correctly provides additional navigation capabilities for screen

reader users

USING LISTS

27

• Tables of data must be identified using HTML table elements:• One <table> element• A <tr> element for each row of the table• A <th> element for each row and column heading• A <td> element for every data cell• A <caption> element to display a visible caption for the table• A <summary> element to provide a synopsis of the table for non-

sighted users• <summary> is not visually displayed• The scope attribute of <th> can be used to indicate that the cell

is a header for a particular row or column• For complex tables, header and id attributes need to be used for

explicit associations

USING TABLES

28

• Insert table in the Rich Text Editor• Select the type of headers:• Top for column headers, left for

rows or both• Create or edit header cells by opening

context menu > cell properties dialog

USING TABLES (CONTINUED)

29

• Provide a meaningful page title for all HTML pages• Specify the title when creating a new HTML page• Edit the page title in the page properties dialog

PAGE TITLES

30

• All form fields need to have meaningful labels• To edit the default label “title” for a form component:

• Open field properties for that component• Edit the label (Title) in the Title & Text tab

• Label (Title) can be hidden but only do this if absolutely necessary• Most screen readers announce hidden labels• For ImageButton components, modifying title modifies the alt text

LABELS FOR FORM FIELDS

31

• Bad example of link text:• click here for details of our evening classes for autumn 2010.

• Good example:

• Evening classes for autumn 2010 – details.

• Screen readers can display list of links in a page for users to navigate

• Title attribute may be used for providing extra instructions• Use of title attribute is not recommended because:• Text in title attribute is only available to mouse users• Assistive Technology support is inconsistent – title attribute

recognition may be turned off by default

LINK PURPOSE AND CONTEXT

32

• Adobe Accessibility Resource Centeradobe.com/accessibility

• Adobe Accessibility Blogblogs.adobe.com/accessibility

• Producing Accessible Sites and Applications using AEM: http://dev.day.com/docs/en/cq/current/administering/supporting-accessibility.html

RESOURCES

33

Q&A