EVOLVE"13 | Maximize & Enhance | Accessibility | Kiran Kaja


Published on

Published in: Design, Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

EVOLVE"13 | Maximize & Enhance | Accessibility | Kiran Kaja

  1. 1. 2 WHAT IS ACCESSIBILITY?  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
  2. 2. 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
  3. 3. 4 THE ACCESSIBILITY 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
  4. 4. 5 GLOBAL ACCESSIBILITY STANDARDS IN 2006 Blue = Standards in effect
  5. 5. 6 GLOBAL ACCESSIBILITY STANDARDS IN 2013 Blue = Standards in effect or policy in development Red = No standards
  6. 6. 7 ACCESSIBILITY 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)
  7. 7. 8 SCREEN READER DEMO Demonstration: PSU Libraries home page with a screen reader.
  9. 9. 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
  10. 10. 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
  11. 11. 12 • A set of technology agnostic Accessibility guidelines developed by W3C http://www.w3.org/TR/WCAG/ • Supported by non-normative documents • Understanding WCAG 2.0 http://www.w3.org/TR/UNDERSTANDING-WCAG20/ • Techniques for WCAG 2.0 http://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 ACCESSIBILITY GUIDELINES (WCAG) 2.0
  12. 12. 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?
  13. 13. 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 users 1. Images need equivalent text 2. Controls need labels that clearly define purpose 3. Controls need to be correctly identified by role, with accurate state and value information provided 4. Relationships present within the content or application needs to be clear 5. Correct reading order 6. Language needs to be correctly identified. WHAT DO BLIND USERS NEED?
  14. 14. 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 users Less 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?
  15. 15. 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 modes 2. Sufficient default color contrast (4.5:1) for all colored content 1. Text 2. Focus caret 3. Controls 3. Instructions that don’t rely on color (e.g. click the red button) WHAT DO COLOR-DEFICIENT USERS NEED?
  16. 16. 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?
  17. 17. 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?
  18. 18. 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
  19. 19. 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
  20. 20. 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
  21. 21. 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
  22. 22. 23 • Advanced Image Properties dialog PROVIDING TEXT ALTERNATIVES
  23. 23. 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
  24. 24. 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
  25. 25. 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
  26. 26. 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
  27. 27. 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)
  28. 28. 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
  29. 29. 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
  30. 30. 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
  31. 31. 32 • Adobe Accessibility Resource Center adobe.com/accessibility • Adobe Accessibility Blog blogs.adobe.com/accessibility • Producing Accessible Sites and Applications using AEM: http://dev.day.com/docs/en/cq/current/administering/supporting- accessibility.html RESOURCES
  32. 32. 33 Q&A