• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Accessibility Integration in a Global Customer Website - Scotiabank.com - A Success Story 2/2
 

Accessibility Integration in a Global Customer Website - Scotiabank.com - A Success Story 2/2

on

  • 1,178 views

The redesign of scotiabank.com presented an ideal opportunity to truly embed accessibility into the project and management processes. ...

The redesign of scotiabank.com presented an ideal opportunity to truly embed accessibility into the project and management processes.

This is presentation 2 of 2. There are two presentations in this series and in both presentations we highlight the most important lessons we learned, best practices that worked and the challenges we faced and how to overcome them. However, they do complement each other:
- the 1st presentation speaks to the governance, policies and management process around the project
- the 2nd presentation describes the accessibility tasks undertaken at each SDLC phase

You'll learn how we gained participation from various stakeholders, shared best practices and built accessibility skills throughout the team.

The accessibility team at Scotia was engaged from the very beginning and collaborated with many stakeholders and as a result took the opportunity to build an accessible framework from day 1 by injecting the accessibility requirements and best practices throughout the entire Software Development Lifecycle Cycle (SDLC).

-- Objectives
The redesign of a large, national website is a complex undertaking. It is also an opportunity to do accessibility right from the beginning.
The objective of the session is to share lessons learned and practical tips about how to successfully integrate accessibility into a large project. This included:
- the ability to work with multiple teams in parallel or sequentially
- working on standards and best practices with the planning team
- working on technical solutions with the development team

-- Some questions that we answered:
- What is the role of the accessibility team in a large project? Does the role need to adapt and how?
- What are the accessibility policies & standards that apply?
- How do you manage and communicate accessibility standards and technical solutions between the various management, design, development and testing teams?
- Do you have to follow WCAG 2 by the letter? What’s the alternative?
We will provide insight into policy, planning, technical solutions and best practices that we hope will be of great benefit and use to the accessibility community.

Statistics

Views

Total Views
1,178
Views on SlideShare
1,177
Embed Views
1

Actions

Likes
0
Downloads
1
Comments
0

1 Embed 1

http://www.verious.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Presentation is in 2 parts: 1 st session: over-arching policies, management processes and the overall environment at Scotia that enabled us to do some really good things on the website 2 nd session: we dig deeper into the solutions, best practices and how it was all managed and communicated between so many teams and internal customers. Remind audience this is an interactive presentation © 2012 Scotiabank
  • Quick team introductions for those who didn’t attend the first session Pina D’Intino  is Senior Manager, Scotiabank Information Technology and Solutions. She is the founder of Enabling Solutions Support Management at Scotiabank and is currently leading the accessibility strategy roadmap from an IT perspective including standards, policy reviews, awareness and education, and inclusiveness as it relates to business.   At Scotiabank, she is a member of the Scotiabank Employment Relationship Council, the founder of the Scotiabankers for Universal Access Employee Resource Group and was a member of the IT&S advancement of women. Pina is the chair of the Canadian Financial Institution on Assistive Technology; bringing together financial organizations to leverage and share accessibility practices and strategies.  She was a member of the AODA Information and Communication Standards Development Committee.   She has been a guest speaker at various International accessibility roundtables and events. Pina travels with her service dog, Gilligan.  Pina has a PMP Master from Schulich and is certified by the ITIL organization. Monica Ackermann  is the Accessibility Project Lead at Scotiabank’s Enabling Solutions Support Management Group and is responsible for implementing systemic IT accessibility solutions and supporting assistive technology users at Scotiabank. She is an accessibility consultant and owner of Assistive Vocational Technology Associates working alongside people with disabilities and their employers in the financial, government, education and commercial sectors helping them to achieve their equity and inclusion goals.    Monica is Systems Design Engineer and member of the PEO and Vocational Rehabilitation Association. While completing her Masters degree in the York University Critical Disability Studies program she explored the intersection of accommodation and accessible software design through both her research into Accessible Technology Infrastructures and as a Research Associate for the DIS-IT research alliance.She was a member of the AODA Employment Accessibility Standards Development Committee and has been a board member at ARCH Disability Law Centre for the past 5 years. George Zamfir  is a Technical Accessibility consultant with Scotiabank’s accessibility team. His focus and passion is IT accessibility and is thrilled to have improved accessibility on some of the biggest web projects at the bank. He had to wear many (technical) hats on various projects including accessibility testing & planning, web development & prototyping and doing many, many bug fixes.    George has a BSc Computer Science from Ryerson University. He stumbled into the field of accessibility during his university years when he worked first as a programmer then as a research assistant under Dr. Deborah Fels in a great research lab called The Center for Learning Technologies. George did his undergraduate thesis on Deaf culture and the benefits of sign-languages on the web.    In his spare time he likes to meddle into other people’s web projects in order to make them (more) accessible. He’s currently volunteering some of his time to CitizenBridge and his wife’s cooking blog.
  • Enabling Solutions & Support Management (ESSM) What is ESSM’s mandate Governance Training Tools AT – IT Solutions Job Accomodation Support IT Accessibilty Education, information, awareness
  • Quickly run through the agenda.
  • - From session 1: The redesign is just phase 1 of 3 of, part of a 3-year project: Year 1 (2010-2011): Design & User Interface, Information Architecture, Applications & Tools, CMS Administration, Search Optimization Year 2 (2011-2012): CMS Software, Infrastructure, Digital Asset Management, Central Content Repository Year 3 (2012-2013): Microsite Repatriation, Adoption of Enterprise CMS by all stakeholders, Centralized CMS Administration Many internal clients, e.g. HR, Communication, Marketing: These are clients that don’t have dedicated web teams and rely on DM for building new functionality, tools, etc. Multiple content owners: HR owns the Career micro-site, Investment Banking owns the iTrade micro-site, etc. 13 templates. For all the content on scotiabank.com
  • We’ve shown this slide in the previous session and just briefly explained what we did at each step. What we’ll do now is we’ll go into the details of every step 1. Planning: Accessibility compliance & checklist 2. Wireframes & Design: Visual logic, navigation, readability 3. HTML Prototype: Full-suite accessibility evaluation & solutioning 4. Steady State: Maintenance, content management, remediation Important notes (we may put this in a slide on its own): - These are the high-level phases of the projects, we won’t go into the breakdown of each phase (e.g. testing: vendor QA, integration testing internally, etc.) - We refer to these phases in the context of accessibility, we left out details of the project that had no impact on accessibility - While the phases look nicely packed in reality they actually overlapped a lot. We couldn’t wait to finish ALL Design templates before moving to prototyping. In fact “Design” & “Prototype” overlapped a lot: we would concurrently work on them in batches, e.g. evaluate Design batch 2 while at the same time test prototype batch 1
  • Meet the project owner early - for them to understand the accessibility internal standards & requirements and decide on where they fit - for ESSM to understand their management & development processes Train all teams on accessibility - Identified all the teams involved & scheduled individual meetings with each to understand how they worked and what processes they followed. - Also, a full-day training was scheduled early on with all the teams involved in the project to establish a baseline for accessibility. Embed accessibility into the project plan In order to avoid doing accessibility “after the fact” time was allocated at each Software Development Lifecycle (SDLC) phase for accessibility evaluations, remediation and (re)test. Start accessibility early (with wireframes) and iterate often; it works with a more agile process where some phases overlapping
  • DESCRIBE THE TEMPLATE ELEMENTS - Top nav, 2 “skip to content” links, text resize - Header: logo, sign in area - Service menu, search - Main menu - Vertical menu – mirrors the main menu - Main Content - Footer
  • Revisit feedback & assumptions from the wireframes phase on Accessible Design, Navigation, Intuitiveness: - Were the recommended updates made? Yes, login / sign in button is much more obvious - Were we right? Do we still need skip links. - More symbol images used, discussion on which are decorative and which offer information and context, which go in the HTML or CSS layers. Colour Contrast : Don’t like that dark grey on light grey - Top menu discussion: We wanted to change to darker gray or black, DM team made the case for branding and colour scheme. Also they brought up a good point: top menu should be there but not distract from the main content on the page and also, based on analytics business users go directly to the business site, not so many switch from personal to business. OK but on focus at least contrast should be better. - Service menu discussion: same but also same links are at the bottom. Bonus: Structure and Interaction : normally you’d have to wait until you have an HTML prototype to talk about it. BUT by having an early look at the design you can make decisions on the structure (headings, lists, etc.) and at least make some assumptions on interactivity and act on them.
  • Process Break templates down into smaller pieces Provide feedback & design updates; identify the “show-stoppers” early Lessons Learned Breaking down the templates (helped a lot) You can see into the future if you look close enough Early fixes on first templates translated into less or repetitive work on following templates AND the HTML prototype
  • Preliminary Evaluation -
  • - Keyboard testing bugs usually mask bigger underlying issues. Example: jQuery dialog unselected=

Accessibility Integration in a Global Customer Website - Scotiabank.com - A Success Story 2/2 Accessibility Integration in a Global Customer Website - Scotiabank.com - A Success Story 2/2 Presentation Transcript

  • Accessibility Integration in a Global Customer Website – A Success Story Part 1: Governance, policies & project management Part 2: SDLC processes, solutions & best practices Enabling Solutions & Pina D’Intino Monica Ackermann Support Management George Zamfir#accessconf - The Accessibility Conference - University of Guelph © 2012 Scotiabank
  • Meet Scotiabank’s Accessibility Team. Hi, again! Enabling Solutions & Support Management (ESSM) Pina D’Intino PMP, ITIL Certified Senior Manager Wilma Groen Monica Ackermann P.Eng., MA Accessibility Project Lead Rajesh Duggal George Zamfir B.Sc. Accessibility Technical AnalystAccessibility Integration in a Global Customer Website – A Success Story
  • Meet Scotiabank’s Accessibility Team. Hi from ESSM!Accessibility Integration in a Global Customer Website – A Success Story
  • Agenda • Quick Overview of 1st session • scotiabank.com Redesign - Let’s Dive Right In • Visual Walk-Through: Wireframes to Production • Step-By-Step Accessibility 3. …And The Journey Continues 4. Tools And Resources 5. Q & AAccessibility Integration in a Global Customer Website – A Success Story
  • 1. scotiabank.com Redesign – Quick Overview (cont’d) • Huge redesign project starting with the Canadian .com • Complex – all tiers from back-end CMS to HTML • Lengthy – a 1-year phase 1 (of 3) project • Many internal clients – all major business lines • Multiple content owners, creators and editors • 13 design templates, that’s it!Accessibility Integration in a Global Customer Website – A Success Story
  • 2. Let’s Dive Right In Project Phase Accessibility Action 1. Planning Accessibility compliance & checklist 2. Wireframes & Design Visual logic, navigation, readability 3. HTML Prototype Testing Full-suite accessibility evaluation & solutioning 4. Steady State Maintenance, content management, remediation High-level phases of the projects that only relate to accessibility In reality it was a fairly agile environment where the phases overlapped a lotAccessibility Integration in a Global Customer Website – A Success Story
  • 2. Let’s Dive Right In – Visual Walk-Through (1) Wireframes – Global Elements
  • 2. Let’s Dive Right In – Visual Walk-Through (2) Wireframes – Header Elements
  • 2. Let’s Dive Right In – Visual Walk-Through (3) Design Template With all elements pieced together
  • 2. Let’s Dive Right In – Visual Walk-Through (4) Prototype & Accessibility Testing
  • 2. Let’s Dive Right In – Visual Walk-Through (5) Production And we’re live!
  • 2. Step-by-Step Accessibility – Planning Meet the project owner early • Understand each other’s operational processes • Identify where the accessibility requirements fit in the project plan Train all teams on accessibility • Individual team meetings: understand strengths & weaknesses • Early full-day accessibility training to establish a baseline for accessibility Embed accessibility into the project plan • Avoids accessibility being an “after the fact” process • Makes a statement for the other SDLC teams; “forced” awareness Start accessibility early and iterate oftenAccessibility Integration in a Global Customer Website – A Success Story
  • 2. Step-by-Step Accessibility – Wireframes Accessibility Evaluation Methodology • Accessible Design & Layout Focusable elements’ size in relation to the layout; Are important UI elements obvious? Maybe login should be bigger? • Navigation Lots of nav menus, maybe we’ll need skip link(s); code order; • Intuitiveness Early but we can still look at symbol-images, visual cues, etc. Are they widely accepted that it makes sense in non-local markets as well?Accessibility Integration in a Global Customer Website – A Success Story
  • 2. Step-by-Step Accessibility – Wireframes (cont’d) Process • Wireframes built by external vendor • Initial review with the project owner • Recommendations to both the owner & vendor • Iterations: test - retest updated versions Lessons Learned • Early phase; not a lot of time spent on it but makes a big difference • Be very proactive & raise potential issues: code order, colour contrast • Send warnings in advance, don’t sit on valuable information. Worst- case scenario: the designers thought about it and it’s a non-issue. • Definitely start accessibility here, nothing is set in stone yet!Accessibility Integration in a Global Customer Website – A Success Story
  • 2. Step-by-Step Accessibility – Design TemplatesBatches of design templates13 templates to accommodate allof Scotia’s contentVery accurate representation ofthe “actual” siteFramework started emerging –global elements (header, footer &nav) vs page-specific contentLet’s break down the scope ofaccessibility into smaller piecesRealized that we’re looking atmain content templates
  • 2. Step-by-Step Accessibility – Design Templates (cont’d) Accessibility Evaluation Methodology • Revisit feedback & assumptions from the wireframes phase • Colour Contrast Dark grey text on light grey background • Visual Order (which will translate into tab order) Odd: the H1 is on top of the vertical nav and the main content. • Readability Great on the H1, anti-aliased, smooth. Good typeface and large text size. • Bonus: Structure and Interaction Framework structure emerged, early recommendations could be made on HTML semantic mark-up: headings, lists, navigation; Early challenge: mega-menus keyboard navigation and interactionAccessibility Integration in a Global Customer Website – A Success Story
  • 2. Step-by-Step Accessibility – Design Templates (cont’d) Process • Break templates down into smaller pieces • Provide feedback & design updates; identify the “show-stoppers” early Lessons Learned • Break the design into smaller pieces (helped a lot) • Clear division of work when doing accessibility testing • Decreased repetition - fixes on the “global elements” are global • You can see into the future if you look close enough Potential issues with interactive elements, semantic mark-up, etc. This is a great chance to make code recommendations. • Early fixes on the first batch translated into more accessible upcoming batches; which in turn eventually translated into a more accessible prototypeAccessibility Integration in a Global Customer Website – A Success Story
  • 2. Step-by-Step Accessibility – HTML Prototype Hopefully that hard work from previous phases is paying off by now… …as the accessibility improvements should be noticeable in the prototype: page structure, informational vs decorative images, etc., even enhancements. Accessibility Evaluation Methodology 1. Preliminary Evaluation (manual testing + code inspection) The goal is to identify critical accessibility issues early such that sufficient time is allocated for reporting and / or solutioning. Also, if other teams do the solutioning they’ll appreciate the heads-up. Pro tip: Great approach in crunch times & also good 80/20 (ish) rule. However, effectiveness relies on the evaluator having expert knowledge 2. Automated Testing Deque Worldspace + FireEyes Provided a quick overview of the initial accessibility levelAccessibility Integration in a Global Customer Website – A Success Story
  • 2. Step-by-Step Accessibility – HTML Prototype (cont’d) Accessibility Evaluation Methodology (cont’d) 3. Thorough Keyboard Testing Two big concepts for keyboard: - Website is fully functional with regular keyboard strokes - All focusable elements have generous keyboard focus Note: A shift from following WCAG 2 where focus is AA requirement 4. Manual Testing + Code Inspection Extensive testing phase; solutions are being built here 5. Full Suite of AT Testing with JAWS / NVDA, ZoomText, Dragon Ideally test with actual AT users or ensure the tester has solid knowledgeAccessibility Integration in a Global Customer Website – A Success Story
  • 2. Step-by-Step Accessibility – HTML Prototype Process • Confirm the previous updates were transitioned in the prototype • Collaborative solutioning with the vendor & dev integrators • Agile iterative process: templates were created in batches and updates were done continuously until the steady state phase Lessons Learned • Automated testing tools can only get your so far. • For the sake of the dev / test teams be consistent in your solutions; but don’t be shy to propose new/better solutions. • Testing with AT users is very valuable: – revealed both a common denominator but also different styles – traditional accessibility solutions may not hold true with ever emerging browsers, AT and even specs – see internal links in Chrome • Careful with some AT: JAWS will guess where accessibility is lacking;Accessibility Integration in a Global Customer Website – A Success Story
  • 2. Step-by-Step Accessibility – HTML Prototype Best Practices • Keyboard testing bugs usually mask bigger underlying issues. • Dynamic elements with show / hide or expand / collapse functionality: • Indicate element state both visually and non-visually • Hard link to the respective area <a href="#tab-rates-fees" class=“active”> Fees & Options <span class=“hidden”> Active tab</span> </a> • Progressive enhancement for interoperability: HTML-CSS-JS-ARIA • ARIA is part of the HTML5 spec but you can use it now in HTML4. However, don’t start your fixes with ARIA when there is a solution lower in the stack in HTML, CSS or JS. Users with browser / AT combinations that don’t support ARIA will be left out. More challenges: dynamic, non-standard UI elementsAccessibility Integration in a Global Customer Website – A Success Story
  • 2. Step-by-Step Accessibility – Steady State Accessibility Evaluation Methodology • Repeat the test procedures from the prototype phase Emphasis on integration issues, look mark-up deviations in HTML • Test at least a few pages per template but run automated testing tools The challenge with large websites is that there are many thousands of pages, manually testing each of them is not realistic. However, testing the most important pages per design template is doable. Process • In this phase the prototype is accessible and approved. And the templates are implemented in the Content Management System (CMS). • Worked with internal dev integration teams in a support capacity. • The website was released in batches and accessibility testing was done after each batch release; the goal was to catch potential issues early.Accessibility Integration in a Global Customer Website – A Success Story
  • 2. Step-by-Step Accessibility – Steady State Challenges • Regular content updates have the potential to dilute accessibility. Start with creating baseline guidelines for content accessibility. Lessons Learned • Expect the unexpected and have a remediation process in place after launch; website launched with some “strange” bugs due to server issues with some of them affecting accessibility. • Not having the capability to detect production bugs quickly increases the risk of compounding issues Ongoing Goals • New content updates: engage the CMS team to enforce some accessibility rules right into CMS back-end • Measure accessibility level over time: regular full website automated testing and reporting on existing content but also on the new content;Accessibility Integration in a Global Customer Website – A Success Story
  • …And The Journey Continues scotiabank.com – umbrella term for future redesign projects Careers Centre It integrates in the .com framework (same header, footer, navigation). Decision on .com to tackle the framework early paid off in testing cycles on this project and any future projects. iTrade Very similar process; noticeable time-savings in testing as a result of using the same proven process and working with more knowledgeable teams.Accessibility Integration in a Global Customer Website – A Success Story
  • Tools • JAWS 11, NVDA 2011.1.1 • ZoomText 9.1 • Dragon Naturally Speaking 11 Automated Testing Tools • Worldspace & FireEyes* • SOAtest Browser Plugins • Firebug • AIS Toolbar • Web Developer • ColorChecker • WebAim WAVEAccessibility Integration in a Global Customer Website – A Success Story
  • Resources Expert solutions, use cases and accessibility resources: webaim.org paciellogroup.com/blog simplyaccessible.com accessibleculture.org alistapart.com/topics/userscience/accessibility Technology Support caniuse.com/wai-aria html5accessibility.com Other Resources stackoverflow.com twitter.com/#!/search/a11yAccessibility Integration in a Global Customer Website – A Success Story
  • scotiabank.com Redesign – Q & A THANK YOU! Time for Q & A !Accessibility Integration in a Global Customer Website – A Success Story © 2012 Scotiabank