Integrating Canadian Accessibility Standards into
your Projects

David Best & Dan Shire
IBM Canada
April 2013 V 0.4
© 2013...
Our agenda
Introduction
Obligations &
opportunities
Accessibility & the
project life cycle
Resources

2
© 2013 IBM Canada ...
Introduction
Accessibility:

3

• Making technology usable by the greatest number of
people, regardless of age or ability
...
Canadians with disabilities increase with age
0-14 years
15-24 years
25-44 years
45-64 years

Population with a
disability...
Introducing AODA Standards
Ontario’s AODA – Accessibility for Ontarians with
Disabilities Act
• World leadership
• Public ...
Obligations – legal and regulatory requirements
Province of Ontario
• The province requires public sector organizations (p...
Opportunity – the case for accessibility
Being accessible makes good business sense — it helps your organization gain a
co...
Opportunity – the case for accessibility

Source: Ontario Accessibility Directorate, 2012
8

http://www.mcss.gov.on.ca/doc...
Timelines for AODA
AODA Compliance Timeline Simplified Summary
Obligated
organization

New content
on existing
Customer
fa...
The consequences of not being accessible
• Organizations are exposed to the threat and cost of litigation,
public relation...
I/T project life cycle (a simplified view!)
Here’s a “generic project model”.
You can unwind this to get a
traditional wat...
Project Initiation and Requirements Definition
Foundations for your project:
• Standards & regulations
• We’ll cover these...
Standards – WCAG 2.0 Level A & AA for the web
WCAG 2.0 Level A – 25 guidelines to meet basic accessibility
WCAG 2.0 Level ...
Design
Who’s involved:
• User experience specialist
• Accessibility specialist
• Information architect
• Graphic designer
...
Build
Who’s involved:
• Developers
• With accessibility training and tools
• Accessibility Compliance Expert
• Responsible...
Test – Functional testing
Who’s involved:
• Development team
• Accessibility Compliance Expert
• Due to the dynamic constr...
Test – Usability testing
Who’s involved:
• Selected end users
• The more accessible the product, the fewer the remediation...
Accessibility testing – rating the issues
Accessibility Severity Guidelines
Sev. 1 – Critical - Must fix to allow even the...
Deploy, support & documentation
Who’s involved:
• Technical writer/editor
• Help desk (support team)
• Accessibility consu...
Training, training and more training
WCAG 2.0
•
•
•
•

38 A & AA requirements (‘success criteria’) – each with techniques
...
Technology challenges
Explosive growth of mobile delivery of I/T solutions
• WCAG 2.0 does not deliver a complete picture ...
Important success factors
Start your journey on the right foot:
•
Adopt proven standards
• WCAG 2.0, with ARIA extensions
...
Questions?

Please contact Dan or David:

Dan Shire
IBM Canada
danshire@ca.ibm.com

David Best
IBM Canada
DaveBest@ca.ibm....
More information – check out these references



Government of Ontario
IBM accessibility checklists





WCAG 2.0 gui...
Cool tools …
1. Plug-ins for Firefox:
 Fangs – screen reader simulator


WAVE – testing toolbar (from WebAIM)

1. NVDA –...
Upcoming SlideShare
Loading in …5
×

STARCANADA 2013 Tutorial: (T16) Integrating Canadian Accessibility Requirements into Your Projects

567 views

Published on

In 2014, most Canadian businesses will face significant challenges as government regulations go into effect, requiring websites to be accessible to users with disabilities. Are your project teams knowledgeable about the technical accessibility standards? Is your business ready to comply with the regulations? Dan Shire and David Best review the key principles of web accessibility (WCAG 2.0) and the government regulations (including Ontario’s AODA) that your organization must meet. Dan provides specific guidance on planning and executing effective accessibility testing and for building your test team skills. David demonstrates testing tools and techniques, including the use of assistive technology including the JAWS screen reader. Together, they will review IBM’s practical experiences: focusing your testing efforts on the most critical standards, selecting your testing tools, building and training your test teams, and prioritizing the results of your accessibility testing to achieve the maximum benefits for the business while minimizing cost and schedule impacts to the project.

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
567
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
3
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Disability rate increases with age:
    0 to 14 years - 3.7% of Canadians have a disability
    15 to 24 years - 4.7%
    25 to 44 years - 8%
    45 to 64 years - 18.3%
    65 to 74 years - 33%
    75 years and over - 56.3%
    Average across all ages = 14.3%
    The Canadian population is aging, the baby boomer generation is contributing to an overall change in the demographic bubble.
  • Canada’s population hit 35 million in December 2012.
    The number of Canadians with disabilities, based on the 2006 PALS study by Statistics Canada is 14.3% of 35 million, or 5 million as of December 2012.
  • Priceline, Ramada, and Target, Best Buy,
    VIA Rail & the Government of Canada
  • Though we can use many models to describe a typical I/T project, this one provides an easy and generic set of phases: initiation and requirements, design, build, test and finally deploy/support.
  • The accessibility evaluation, throughout the product life cycle, should focus on 4 categories (Perceivable, Operable, Understandable, Robust), with each accessibility issue assigned a severity level.
    Accessibility Compliance Guidelines 1. perceivable - User agents, like screen readers, require clearly defined HTML elements within a structured DOM. The ARIA Landmarks and a hierarchy of Headers should be used to define page regions and content context. The Banner, Navigation panel, Main section, and Footer are visually perceivable on a standard computer screen, but is not on a screen reader device. 2. operable - All web page elements must be operable by a keyboard, speech input, and other non-mouse devices. Some of the Java scripts may not be keyboard accessible, and preventing non-mouse users from performing some functions. 3. understandable - Page Titles must be unique and meaningful. Links and Buttons must have concise and clearly marked text labels. Images must have descriptive alternative text. The page foreground and background, and Icons, must have contrasting colours for low vision users. The web page must have clearly defined user instructions, and a separation of information content. 4. robust - To deliver a desirable user experience, there must be a separation between web page design and user content. The web page may not render as expected in all browsers, and will not perform as expected in differing user agents. A design utilizing style sheets and Dojo widgets may improve the robustness. Note, the WAI ARIA code should only be used on a web page if the native HTML code cannot implement the desired DOM effect. ARIA code will not have any effect on older browsers. The Web Accessibility Initiative Accessible Rich Internet Applications (WAI-ARIA) specification has varying degrees of implementation between JAWS, ZoomText, Window-Eyes, NVDA and VoiceOver, and between versions of each of these products. Moreover, WAI-ARIA implementation varies among browser brands and versions. This is why it is important that any accessibility solution which implements WAI-ARIA is coupled with a non-ARIA fallback solution.
  • Skill: User interface (user focus groups)
    Comment: Wire frames must include components that describe the required user interface (mouse, keyboard, touch screen, speech, Etc.) interaction with user agents. Depending upon the product, this may involve user group studies to gain an understanding of adaptive technologies and user behaviour. This understanding is important for reducing time and cost at later product life cycle phases.
    Skill: Wire frames (Accessibility Consultant)
    Comment: Web page functional components must meet user expectations. Understanding the user needs, and the attribute properties of web page elements, will have an impact on the cost and time for development. The page landscape must be perceivable, the content understandable, the objects operable, and the overall usability must be robust.
  • Skill: Development (Accessibility Compliance Expert)
    Comment: The first task is to assign a team member the role of Accessibility Liaison. This person will be responsible for coordinating accessibility status meetings throughout the development process, define accessibility testing scenario plans, conduct accessibility testing sessions, and monitor accessibility remediation efforts. This requires an understanding of the compliance certification procedures, available automated testing tools, and usability testing requirements. An accessibility integrated testing strategy is critical during development.
  • Skill: Development (Accessibility Compliance Expert)
    Comment: Due to the dynamic construction of complex web sites it is necessary to repeat accessibility compliance testing at all levels of development (Alpha, Beta, Production). Dynamic page rendering and operable functionality must be thoroughly tested before usability testing begins. Where native HTML5 cannot meet accessibility requirements, then WAI-ARIA coding can be implemented. Java scripts and widgets (JQuery, Dojo) must be robust.
  • Skill: End users (Adaptive Technology Users)
    Comment: At some point during the development, functional and usability testing will take on greater importance. The more accessibility mature the product is the fewer the remediation cycles that will be needed. First, usability testing is performed by an Accessibility Specialist with automated accessibility compliance tools. Secondly, usability user experience testing is performed by end-user adaptive technology users. This may include users from the various disability groups (vision, hearing, cognitive, mobility, medical, and others). If the functional compliance testing and required remediation implementation, is not performed properly, the end user experience testing will be frustrating and costly. To be effective the usability test phase must be conducted with well defined use test scenario scripts, as the end users may not have technical skills or have product background understanding.
  • Accessibility Severity Guidelines
    1. critical - Must fix to allow even the most basic use of the application.        User with a disability cannot complete a task, and no alternate means is provided to complete that task. The issue is a violation of the Web Accessibility Checklist. 2. high - Must fix in order to meet accessibility standards and allow full use of the system.        User with a disability will likely not be able to easily complete a task, and no alternate means is provided to complete the task. The issue is a violation of the Web Accessibility Checklist. 3. medium - Should fix to allow productive, accessible use of the application.        User with a disability will likely be able to complete a task, but the issue prevents the user from completing the task efficiently. The issue may or may not be a violation of the Web Accessibility Checklist. 4. low - Should be addressed in next release.        User with a disability will be able to complete a task, but the issue may cause confusion to the user, and should be resolved. The issue is not a violation of the Web Accessibility Checklist. An issue was found, but should not be classified as an accessibility problem. These may be functionality bugs that should be corrected.
  • Roles and Skills – Help desk (support), Accessibility Consultant
    Comment: Once a product is released into production, there should be a feedback mechanism to continue evaluating the user experience. The many different browsers, user agents, and version levels, will render a wide variety of user experience results. This feedback will help improve the robustness of your product in later releases.
    The accessibility evaluation, throughout the product life cycle, should focus on 4 categories (Perceivable, Operable, Understandable, Robust), with each accessibility issue assigned a severity level.
  • Robust part of testing – most users don’t have the latest technology so you need to consider users with older versions of screen readers, etc.
    Wide variety of browsers and user agents will contribute to a wide range of user experience (some of these could be poor).
    Need to define a baseline and communicate it clearly.
  • Reference sites:
    Government of Ontario www.ontario.ca/AccessON
    IBM accessibility checklistswww.ibm.com/able
    WCAG 2.0 guidelineswww.w3.org/WAI
    W3C – good & bad website examples www.w3.org/WAI/demos/bad/
    Worldwide Web Consortium (W3C) page on user testing
    webbism.com/2012/07/06/the-benefits-of-user-testing-with-disabled-users/www.w3.org/wiki/Accessibility_testing#When_should_testing_be_done.3F
    WCAG sufficient techniques www.w3.org/TR/UNDERSTANDING-WCAG20/intro.html#introduction-layers-techs-head
    Involving Users in Evaluating Web Accessibility
    www.w3.org/WAI/eval/users
    Involving Users in Web Projects for Better, Easier Accessibility www.w3.org/WAI/users/involving.html
    WebAIM Utah State Universitywww.webaim.org
    OCAD University – Inclusive Designwww.idrc.ocad.ca
    Government of Canada Web Experience Toolkit
    www.tbs-sct.gc.ca/ws-nw/wa-aw/wet-boew/index-eng.asp
  • Cool tools – links
    Plug-ins for Firefox:
    Fangs – screen reader simulator
    WAVE – testing toolbar (from WebAIM)
    NVDA – free open source screen reader
    www.nvda-project.org
    JAWS – screen reader – evaluation copy
    www.freedomscientific.com/products/fs/jaws-product-page.asp
    IBM aDesigner – free open source accessibility simulator and test tool www.eclipse.org/actf/downloads/tools/aDesigner
  • STARCANADA 2013 Tutorial: (T16) Integrating Canadian Accessibility Requirements into Your Projects

    1. 1. Integrating Canadian Accessibility Standards into your Projects David Best & Dan Shire IBM Canada April 2013 V 0.4 © 2013 IBM Canada Ltd.
    2. 2. Our agenda Introduction Obligations & opportunities Accessibility & the project life cycle Resources 2 © 2013 IBM Canada Ltd.
    3. 3. Introduction Accessibility: 3 • Making technology usable by the greatest number of people, regardless of age or ability • Breaking down technical and organizational barriers that hinder the full participation and contribution of: – Our customers – Our employees – Our family members – Ourselves • Individuals have unique requirements and may use assistive technology to help them overcome specific barriers in order to access information and services: – Vision – Hearing – Mobility – Dexterity – Learning/cognitive © 2013 IBM Canada Ltd.
    4. 4. Canadians with disabilities increase with age 0-14 years 15-24 years 25-44 years 45-64 years Population with a disability by age (2006) 3.7% 4.9 million Canadians 4.7% 8% 18.3% 33% 65-74 years 56.3% 75+years All ages 14.3% Source: Statistics Canada. Participation and Activity Limitation Survey 2006: Tables. Ottawa: Statistics Canada, 2007 (Cat. No. 89-628-XIE - No. 003). 4 © 2013 IBM Canada Ltd.
    5. 5. Introducing AODA Standards Ontario’s AODA – Accessibility for Ontarians with Disabilities Act • World leadership • Public and private sector • Specific requirements – timelines and measurable • A consultative process • 5 components – – – – – 5 Customer Service Information and Communication Transportation Employment Built Environment • All public sector organizations in Ontario are under the AODA • 360,000 private sector businesses (provincially regulated) • 20,000 private sector businesses (>50 employees) have additional obligations under the regulations © 2013 IBM Canada Ltd.
    6. 6. Obligations – legal and regulatory requirements Province of Ontario • The province requires public sector organizations (province, municipal, colleges, universities, hospitals, etc) to provide accessible customer service and accessible web sites. • The requirement for accessible information - web, content, other communication - under the AODA. Government of Canada • The federal government was sued and convicted because citizen-facing web sites were not fully accessible. Business in Canada • Larger companies in Ontario (> 50 employees) fall under more stringent Ontario regulations – external web sites and internal IT systems must meet WCAG 2.0 accessibility requirements. • 360,000 businesses in Ontario are affected by the provincial regulations. – US and international standards are often a factor Business in the United States • Federal contracts are obligated by S508. • Federal, state and local by the Americans with Disabilities Act (ADA) • Businesses are obligated by the ADA • Risk mitigation influences many companies 6 © 2013 IBM Canada Ltd.
    7. 7. Opportunity – the case for accessibility Being accessible makes good business sense — it helps your organization gain a competitive advantage in growing markets, increase revenue and retain employees. People with Disabilities 16% of world population Aging By 2025, 20% of industrialized world population will be over age 65 Canadian population: Canadians with disabilities: Non-native language speakers Globalization the driver People with low literacy & novice ICT users Rising tide of new users Everyday situations “Temporarily disabled” Driving – eyes busy Noisy environment 35 Million ~ 5 Million Accessibility extends the capabilities of technology to accelerate social innovation and create shared value for all the citizens of our Smarter Planet. 7 © 2013 IBM Canada Ltd.
    8. 8. Opportunity – the case for accessibility Source: Ontario Accessibility Directorate, 2012 8 http://www.mcss.gov.on.ca/documents/en/mcss/accessibility/Ont_InfoGraph-EN.pdf © 2013 IBM Canada Ltd.
    9. 9. Timelines for AODA AODA Compliance Timeline Simplified Summary Obligated organization New content on existing Customer facing sites New Customerfacing sites All Customer facing sites and content (legacy sites & content) Private Sector with > 50 employees (20,000 businesses in Ontario) WCAG 2.0 A Jan. 1, 2012 WCAG 2.0 A Jan. 1, 2014 WCAG 2.0 AA Jan. 1, 2021 ** 2013 – 2017 WCAG 2.0 A Jan. 1, 2014 WCAG 2.0 AA Jan. 1, 2021 ** 2013 - 2017 WCAG 2.0 AA Jan. 1, 2012 ** WCAG 2.0 AA Jan. 1, 2016 ** Municipalities and other public sector (universities, Customer & Citizen facing sites, and Employee sites Employment – accommodation plans & accessible formats and communication supports hospitals, schools…) Government of Ontario WCAG 2.0 AA Jan. 1, 2012 WCAG 2.0 AA Jan. 1, 2020 2013 - 2017 ** Except 1.2.4 Live captions and 1.2.5 Pre-recorded audio descriptions. Not intended to be a legal opinion – consult the regulations and your organization’s legal counsel for specifics. http://www.e-laws.gov.on.ca/html/source/regs/english/2011/elaws_src_regs_r11191_e.htm 9 © 2013 IBM Canada Ltd.
    10. 10. The consequences of not being accessible • Organizations are exposed to the threat and cost of litigation, public relations issues, and loss of government contracts. – Private companies, such as Priceline, Ramada, and Target have been sued for not having accessible Web sites and the organizations were forced to pay hefty fines and agree to re-design their sites to make them more accessible. – Designing for accessibility from the beginning is significantly less expensive than re-design after the fact, especially under courtmandated pressure. – In Canada: VIA Rail, the Government of Canada and the Toronto Transit Commission (TTC) have been charged and convicted • Most government entities in the U.S., Europe, Australia, New Zealand and Japan are required to comply with some form of accessibility standards and regulations. • Procurement challenges - for private sector clients that supply services & products to the government, overlooking accessibility requirements can result in lost contracts and lost revenue, or penalties. 10 © 2013 IBM Canada Ltd.
    11. 11. I/T project life cycle (a simplified view!) Here’s a “generic project model”. You can unwind this to get a traditional waterfall project or compress the timeframe to get an agile project iteration cycle. Initiation & Requirements Design Deploy/ support Users Test User experience, including accessibility and support for universal design, should be at the heart of your project – this can be integrated into every phase of the project. Build Next, we’ll look at the benefits, implications, roles and skills for each of these project stages. 11 © 2013 IBM Canada Ltd.
    12. 12. Project Initiation and Requirements Definition Foundations for your project: • Standards & regulations • We’ll cover these on the next slide • • • • • • Organizational Governance Project methodology Training and Experience • Specific to team roles Technology • Development and testing Tools Procurement policy • Your success is dependant on your vendors, suppliers and partners – test them! Who’s involved: • Project sponsor • Solution architect • Business analysts • Project manager Work products: • Business case • Solution architecture • High level functional and non-functional requirements • Use cases • Personas 12 © 2013 IBM Canada Ltd.
    13. 13. Standards – WCAG 2.0 Level A & AA for the web WCAG 2.0 Level A – 25 guidelines to meet basic accessibility WCAG 2.0 Level AA – 13 additional guidelines provide more robust support 13 Perceivable • Provide text alternatives for non-text content. • Provide captions and alternatives for audio and video content. • Make content adaptable; and make it available to assistive technologies – images with labels. • Use sufficient contrast to make things easy to see and hear – contrast and colour. Operable • Make all functionality keyboard accessible – tabbing order. • Give users enough time to read and use content. • Do not use content that causes seizures (flashing). • Help users navigate and find content. Understandable • Make text readable and understandable – clear language • Make content appear and operate in predictable ways – headings, structure. • Help users avoid and correct mistakes. Robust • Maximize compatibility with current and future technologies. © 2013 IBM Canada Ltd.
    14. 14. Design Who’s involved: • User experience specialist • Accessibility specialist • Information architect • Graphic designer • User focus groups • Developers with code design experience 14 Work products: • Creative design • The look and feel of the application, including branding. • Wire frames • Include components that describe the required user interface (mouse, keyboard, touch screen, speech, etc.) and interaction with user agents. • This may involve user group studies to gain an understanding of adaptive technologies and user behaviour. • Responsive design – gracefully support multiple devices from traditional PC to smart phones • Web page functional components must meet user expectations. • The page landscape must be perceivable, the content understandable, the objects operable, and the overall usability must be robust. © 2013 IBM Canada Ltd.
    15. 15. Build Who’s involved: • Developers • With accessibility training and tools • Accessibility Compliance Expert • Responsible for planning, coordinating and monitoring the accessibility testing throughout the development process • Requires an understanding of the compliance certification procedures, available automated testing tools, and usability testing requirements. An integrated testing strategy for accessibility is critical during development. Work products: • Functional code • Robust code which has been built and unit tested with tools that enforce (or at a minimum enable support for) the WCAG 2.0 guidelines • Accessibility test plan/strategy • There are 3 typical elements to accessibility testing: automated testing to identify basic issues, manual testing using specialized tools (e.g. browser plug-ins), and selective testing using assistive technology such as ZoomText and JAWS. 15 © 2013 IBM Canada Ltd.
    16. 16. Test – Functional testing Who’s involved: • Development team • Accessibility Compliance Expert • Due to the dynamic construction of complex web sites it is necessary to repeat accessibility compliance testing at all levels of development (Alpha, Beta, Production). • Dynamic page rendering and operable functionality must be thoroughly tested before usability testing begins. Where native HTML5 cannot meet accessibility requirements, then WAI-ARIA coding can be implemented. Java scripts and widgets (JQuery, Dojo) must be robust. • Test the application, and the documentation Work products: • Functional, accessible application code • Tested: automated, manual and assistive technology techniques • Test report • Accessibility issues documented & tracked • Remediation steps identified 16 © 2013 IBM Canada Ltd.
    17. 17. Test – Usability testing Who’s involved: • Selected end users • The more accessible the product, the fewer the remediation cycles are likely to be needed in the future. • User experience testing is performed by end-user adaptive technology users. • This may include users from the various disability groups (vision, hearing, cognitive, mobility). • If the functional compliance testing and required remediation implementation is not performed properly, the end user experience testing will be frustrating and costly. • To be effective the usability test phase must be conducted with well defined user experience test scripts – don’t “wing it”. • User experience specialist & Accessibility Compliance Expert Work products: • Usability test report • User experience and accessibility issues identified, documented & tracked • Remediation steps identified 17 © 2013 IBM Canada Ltd.
    18. 18. Accessibility testing – rating the issues Accessibility Severity Guidelines Sev. 1 – Critical - Must fix to allow even the most basic use of the application. User with a disability cannot complete a task, and no alternate means is provided to complete that task. The issue is a violation of the Web Accessibility Checklist. Sev. 2 – High - Must fix in order to meet accessibility standards and allow full use of the system. User with a disability will likely not be able to easily complete a task, and no alternate means is provided to complete the task. The issue is a violation of the Web Accessibility Checklist. Sev. 3 – Medium - Should fix to allow productive, accessible use of the application. User with a disability will likely be able to complete a task, but the issue prevents the user from completing the task efficiently. The issue may or may not be a violation of the Web Accessibility Checklist. Sev. 4 – Low - Should be addressed in next release. User with a disability will be able to complete a task, but the issue may cause confusion to the user, and should be resolved. The issue is not a violation of the Web Accessibility Checklist. An issue was found, but should not be classified as an accessibility problem. These may be functionality bugs that should be corrected. 18 © 2013 IBM Canada Ltd.
    19. 19. Deploy, support & documentation Who’s involved: • Technical writer/editor • Help desk (support team) • Accessibility consultant • User experience specialist & Accessibility Compliance Expert Work products: • Training and guidance for the help desk – supporting customers or employees who use assistive technology • When the application or product is released into production, there should be a feedback mechanism to continue evaluating the user experience. The many different browsers, user agents, and version levels, will render a wide variety of user experience results. This feedback will help improve the robustness of your product in later releases. • Support costs can be significant, there may be customer satisfaction or legal risks associated with inappropriate application support • Under the AODA, there are obligations and penalties for customer support. • Accessible documentation • Compliant with the WCAG 2.0 standards – MS Office, PDF, captioned video, etc. 19 © 2013 IBM Canada Ltd.
    20. 20. Training, training and more training WCAG 2.0 • • • • 38 A & AA requirements (‘success criteria’) – each with techniques www.w3.org/WAI/WCAG20/quickref www.ibm.com/able www.ontario.ca/AccessON Everyone on the team needs some training • • • • • • • • • 20 Project stakeholders Project manager Business analysts User eXperience specialist (UX) & Information architects Web Designers Software developers Quality assurance experts Accessibility Compliance Expert Technical writers (application documentation) The first couple projects will cost more – there’s a training, tools and organizational learning curve. You cannot avoid this investment. The cost of remediation is much higher than the investment to design it and build it right up front. © 2013 IBM Canada Ltd.
    21. 21. Technology challenges Explosive growth of mobile delivery of I/T solutions • WCAG 2.0 does not deliver a complete picture for tablets and smart phones • Most mobile devices will not have a traditional keyboard but that doesn’t mean they cannot be accessible • Most mobile applications are hybrid applications and not simply Web • Mobile platforms are incomplete in their accessibility services support Social media • Despite rapid adoption rates, social media channels are still largely inaccessible… • Social businesses will perpetuate and widen this gap unless inclusive solutions are provided Growth of big data and analytics • I/T solutions increasingly requires the effective use of business analytics 21 • This is an area where the accessibility technology community has done a poor job – representation of complex data and inter-relationships of the data in a way that is clear and understandable, and which is accessible with assistive technologies © 2013 IBM Canada Ltd.
    22. 22. Important success factors Start your journey on the right foot: • Adopt proven standards • WCAG 2.0, with ARIA extensions • On-going training for developers and testers • On-going awareness sessions for the project sponsor and other stakeholders to maintain support • Align with good user experience principles • Organizational Support: Executive Champion • Governance - Legal, procurement accessibility clause in contracts and RFP’s • Work with groups such as HR with a heightened and focused awareness of disability issues • Pick your first project carefully • Work with groups involved in highly visible customer facing applications • But, don’t overreach – don’t try to boil the ocean on the first project • Identify and get commitment on the accessibility requirements at the earliest possible stage - in the conceptual and business case process • • • • • Development environment • Consider a dedicated Portal for sharing and distribution of information, resources and downloadable testing tools • Integrate your accessibility testing tools with development and standard testing tools and processes Testing environment • Controlled and structured – all the testing disciplines and techniques you understand can be applied to improve your odds of success Be innovative and thought provoking Create repeatable and scalable solutions Embrace collaboration – between industry and vendors and colleagues 22 © 2013 IBM Canada Ltd.
    23. 23. Questions? Please contact Dan or David: Dan Shire IBM Canada danshire@ca.ibm.com David Best IBM Canada DaveBest@ca.ibm.com 23 © 2013 IBM Canada Ltd.
    24. 24. More information – check out these references   Government of Ontario IBM accessibility checklists    WCAG 2.0 guidelines www.w3.org/WAI W3C – good & bad website examples www.w3.org/WAI/demos/bad/ Worldwide Web Consortium (W3C) page on user testing www.ontario.ca/AccessON www.ibm.com/able webbism.com/2012/07/06/the-benefits-of-user-testing-with-disabled-users/www.w3.o       24 WCAG sufficient techniques www.w3.org/TR/UNDERSTANDING-WCAG20/intro.html#introduction-layerstechs-head Involving Users in Evaluating Web Accessibility www.w3.org/WAI/eval/users Involving Users in Web Projects for Better, Easier Accessibility www.w3.org/WAI/users/involving.html WebAIM Utah State University www.webaim.org OCAD University – Inclusive Design www.idrc.ocad.ca Government of Canada Web Experience Toolkit www.tbs-sct.gc.ca/ws-nw/wa-aw/wet-boew/index-eng.asp © 2013 IBM Canada Ltd.
    25. 25. Cool tools … 1. Plug-ins for Firefox:  Fangs – screen reader simulator  WAVE – testing toolbar (from WebAIM) 1. NVDA – free open source screen reader www.nvda-project.org 1. JAWS – screen reader – evaluation copy www.freedomscientific.com/products/fs/jaws-product-page.asp 1. IBM aDesigner – free open source accessibility simulator and test tool www.eclipse.org/actf/downloads/tools/aDesigner 25 © 2013 IBM Canada Ltd.

    ×