Your SlideShare is downloading. ×
Web Accessibility in the Hospitality Industry
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Web Accessibility in the Hospitality Industry

540

Published on

This presentation discusses the current state of web accessibility in the hospitality industry, recent litigations, applicable regulations and how to best implement a web accessibility program.

This presentation discusses the current state of web accessibility in the hospitality industry, recent litigations, applicable regulations and how to best implement a web accessibility program.

Published in: Travel
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
540
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • The  hospitality industry  is a broad category of fields within the service industry that includes lodging, restaurants, event planning, theme parks, transportation, cruise lines and additional fields within the tourism industry. The hospitality industry is a several billion dollar industry that mostly depends on the availability of leisure time and disposable income. A hospitality unit such as a restaurant, hotel, or even an amusement park consists of multiple groups such as facility maintenance, direct operations (servers, housekeepers, porters, kitchen workers, bartenders, etc.), management, marketing, and human resources.
  • Litigation risk is the potential costs to an organization from complaints, litigation, damages and injunctions. The costs include lawyer fees, time lost to address the issues of the case, direct costs from damages in the case and the cost to retrofit the site into compliance. Collectively these direct and indirect costs are significant and on the order of 10M for a general high volume site. Note: This analysis doesn’t include the negative brand connotations for a provider that is actively barring people with disabilities from using the systems. Plaintiffs will try cases both in the courts and in the press. Risk is roughly correlated to their transaction volume of a system. Transaction volume would be a weighted measure of the number of discrete transactions with constituents executed on the site. The public profile relates to the focus of your public site – either general public or specific user. General public focused sites bear more risk than specific use sites. Lawsuit costs generally include legal fees, damages and injunctions on development. Cost to average enterprise system can generally tops 10M for litigation that is drawn out. Complaints and litigation have started to rise in recent months. Cases frequency has doubled in the last year and complaint are up a similar amount. Bottom line if you haven’t received a complaint yet you will in the near future. More generally, the way that legal risk is often transferred to software companies is via contract representations, modifications to products in the field and overly broad compliance claims. Essentially all these come down to when a company makes inaccurate or poorly informed claims of compliance either in sales, contracting or consulting services activities. These risks can generally be addressed by providing some form of third party reviewed or validated accessibility statements such as a VPAT. Settlement References http://lflegal.com/category/settlements/ http://www.dralegal.org/cases/index.php http://www.dralegal.org/cases/private_business/nfb_v_target.php http://www.dralegal.org/downloads/cases/tucker/exhibits/Exhibit_S.doc http://www.dredf.org/ http://www.ag.ny.gov/media_center/2009/sep/sep1a_09.html
  • Organizations generally rollout accessibility using a six stage process Policy Development - Develop the core accessibility policy, target standards and timeline. This includes things like: Accessibility Policy - Overall Accessibility Policy that defines the target standards and requirements to focus on for accessibility Accessibility Issue Resolution Policy - Escalation and resolution path for issues relating to ICT accessibility. Accessibility Quality Control Plan - Define extensions to the current development process to ensure that accessibility is properly validated throughout the development process. It will include extensions to roles to define accessibility testing responsibilities as well as the setup of specific accessibility gateways throughout the development process. At each of these gateways accessibility will be tested and validated at a level of detail appropriate for that stage of the development process. Accessibility Monitoring Plan - Define the systems and methodologies in place to monitor production systems for accessibility. Notably this plan should provide for active, automatic testing as part of as part of standard functional regression and monitoring testing. This would include activities related to the setup of the initial monitoring, testing of the monitoring for scope and accuracy for a given web property, and deployment of monitoring reports to relevant site owners. Procurement and Contracting Policy - Procurement and contracting policy that compliments the Accessibility Policy. Ensure contractors and vendors conform to requirements and contracting recourse for non-compliance is provided. Standards Development  – Define the technical standards and supporting documentation for implementing the standards. Implementation Plan Development  – Develop the implementation plan for rolling out the policy and standards across the organization. System Survey and Analysis - A survey and analysis that defines all systems that will fall under the scope of the accessibility policy. This would include, but not be limited to, all public and employee facing systems Internet and Intranet applications. Accessibility Project Management Plan - Define the timeline, milestones, activities and staff required to implement the overall accessibility plan. The PMP will include: A detailed schedule that defines the individual activities of the work effort and any dependency of groupings amongst activities. For each activity, the plan will identify duration, location, participants, roles and responsibilities, milestones and dependencies amongst activities; Staffing requirements and job descriptions for any additional full or partial staff required to successfully implement that plan; Cost estimates for any investments required to implement the plan; A risk plan outlining potential project risks and risk mitigation strategies; and A communication plan outlining the standard communication protocols, e-mail distribution lists and communication escrow policies for the project. Training Development – Develop the training plan, eLearning modules and training courses used to train the various different roles. Pilot Implementation  – Implement the accessibility standards in key, high risk systems. Full Deployment – Deploy the standards and policy across the organization
  • Organizations generally rollout accessibility using a six stage process Policy Development - Develop the core accessibility policy, target standards and timeline. This includes things like: Accessibility Policy - Overall Accessibility Policy that defines the target standards and requirements to focus on for accessibility Accessibility Issue Resolution Policy - Escalation and resolution path for issues relating to ICT accessibility. Accessibility Quality Control Plan - Define extensions to the current development process to ensure that accessibility is properly validated throughout the development process. It will include extensions to roles to define accessibility testing responsibilities as well as the setup of specific accessibility gateways throughout the development process. At each of these gateways accessibility will be tested and validated at a level of detail appropriate for that stage of the development process. Accessibility Monitoring Plan - Define the systems and methodologies in place to monitor production systems for accessibility. Notably this plan should provide for active, automatic testing as part of as part of standard functional regression and monitoring testing. This would include activities related to the setup of the initial monitoring, testing of the monitoring for scope and accuracy for a given web property, and deployment of monitoring reports to relevant site owners. Procurement and Contracting Policy - Procurement and contracting policy that compliments the Accessibility Policy. Ensure contractors and vendors conform to requirements and contracting recourse for non-compliance is provided. Standards Development  – Define the technical standards and supporting documentation for implementing the standards. Implementation Plan Development  – Develop the implementation plan for rolling out the policy and standards across the organization. System Survey and Analysis - A survey and analysis that defines all systems that will fall under the scope of the accessibility policy. This would include, but not be limited to, all public and employee facing systems Internet and Intranet applications. Accessibility Project Management Plan - Define the timeline, milestones, activities and staff required to implement the overall accessibility plan. The PMP will include: A detailed schedule that defines the individual activities of the work effort and any dependency of groupings amongst activities. For each activity, the plan will identify duration, location, participants, roles and responsibilities, milestones and dependencies amongst activities; Staffing requirements and job descriptions for any additional full or partial staff required to successfully implement that plan; Cost estimates for any investments required to implement the plan; A risk plan outlining potential project risks and risk mitigation strategies; and A communication plan outlining the standard communication protocols, e-mail distribution lists and communication escrow policies for the project. Training Development – Develop the training plan, eLearning modules and training courses used to train the various different roles. Pilot Implementation  – Implement the accessibility standards in key, high risk systems. Full Deployment – Deploy the standards and policy across the organization
  • There are three questions that you have to be able to answer in the affirmative if you are to be considered compliant? Did we write the application in a fashion that conforms to the coding requirements in the relevant standards? ( Technical Requirements ) Can people with disabilities using the application complete the core tasks of the application? Alternatively, does the application as a whole produce an accessible experience? ( Functional Requirements ) Is the deployment context of the application accessible? Does the information, documentation, support and training produce an accessible experience? ( Support Requirements ) Technical Requirements Automatic tests are requirements that can be tested for automatically with a high degree of certainty. Automatic testing can cover around 25% of applicable accessibility requirements the rest of which need to be tested manually or globally. Automatic tests generally don’t allow you to full determine compliance with the laws, f or example: Tools can test for the presence of alternative text but not if the text is a meaningful replacement Tools can test for the presence of form field labels but not if assistive technology users can fill out a form Manual testing relates to the issues that can be validate on a page-by-page (module-by-module) basis but can’t be validate across the entire application. All requirements that don’t fit the automatic profile are by nature manual requirements. Global testing relates to the issues that can be tested once or a small number of times and extrapolated across the entire application Things to think about when determining technical requirement testing coverage: What automated testing tool do you currently have in place? Do you have a checklist in place for global and manual testing? How long and detailed is the checklist? How do you store the results for your global and manual testing? Functional Requirements Functional requirements have to do with the usability of the system by individuals with disabilities. Technical requirements focus on the trees – functional requirements on the forest. Things to think about when determining technical requirement testing coverage: What individuals with disabilities do you use to test applications? Do you have individuals who are blind testing your application with JAWS 10? Window-Eyes 7? How do you capture new requirements as they are found in functional testing? AN APPLICATION MUST CONFORM TO BOTH THE TECHNICAL AND FUNCTIONAL REQUIREMENTS TO BE COMPLIANT Support Requirements Is the documentation of the application accessible? Do I have means of providing accessible support for the application? TTY / TDD? Accessible online chat? Is the training that supports the application accessible?
  • The testing process is broken down into three key phases – Groundwork, Testing and Reporting. The Groundwork and testing phases have two tracks – normative testing which validates the application against a set of best practices and functional testing which validates the overall use of the application. Groundwork - During the groundwork phase, the actual portions of the system that are identified and prepared for the different forms of testing that are performed by SSB. The testing scope includes two key components - the module list and the use case list. The modules that are selected are a "representative" set of interface components - pages, screens, visual components, controls, etc. - that are found in the system. These are the modules that will be tested with SSB's exhaustive automated, global and manual testing methodology which collectively defines our normative testing approach. The use cases reflect a representative set of "core tasks" that are performed by users of the system. Each use case is formally scripted to define the sequence of steps that the user performs to complete that task. These are the core tasks that users with disabilities will test with the leading assistive technologies. The lists of modules and use cases are somewhat independent of each other, but the most important or complex features of the system will be reflected in both lists. Testing - Once the lists of modules and use cases have been finalized by SSB and approved by the client, our team will test the system using SSB's proprietary methodology. The testing is broken into two broad categories. Normative testing utilizes automated testing tools where they are viable, global issue review and manual testing. The Normative testing approach general maps to the Section 508 technical standards previously discussed. Functional Testing includes testing by individuals that are blind or disabled using the leading assistive technologies. This functional testing approach generally maps to the Section 508 functional requirements previously discussed. In this fashion we can determine both the technical and functional compliance of the application in one testing process. Reporting Analysis - After the completion of the testing phase SSB's testing team will cross-validate the manual, use case, and automated testing results and synthesize them into a single compliance data set. The data set will then be analyzed for violations that occur in patterns as well as in isolation, and will map specific violation descriptions against the modules on which each was found. The analysis phase also translates the large amounts of raw data produced in the testing phase into a clear, concise, prioritized set of recommendations. This ensures that recipients of the report receive not just a list of issues but a prioritization defining what issues are most important to address first. Delivery – Finally SSB presents the report online or onsite to all relevant stakeholders across applicable functional groups. This presentation serves to raise awareness of compliance within the product groups and allow for the clarification of report findings across all affected functional groups.
  • Transcript

    • 1. Web Accessibility in the Hospitality Industry October 25, 2012 Presented By: Eduardo Meza-Etienne, Senior Account Manager Debra Ruh, Chief Marketing Officer The session is scheduled to begin at 2:00pm Eastern Time We will be testing sound quality periodically Audio and Visual are provided through the on-line webinar system This session is closed captionedSilicon Valleyand materials of this session are the property of SSB Bart Group and the presenters and cannot be used and/or distributed 637-8955 The content (415) 975-8000 www.ssbbartgroup.com Washington DC (703)
    • 2. Review of Webinar Features Closed captioning – click CC icon (located in the panel labeled “Audio and Video” on your screen) and adjust the captioning box as needed for font size, contrast, etc. Customize your view – You can resize the whiteboard where the Presentation slides are shown to make it smaller or larger by choosing from the drop down menu located above and to the left of the whiteboard. The default is “fit page” 2
    • 3. Review of Webinar Features Asking ?’s – Participants may submit questions via the chat area (Ctrl M) or may use a microphone to ask their question “live”. If you want to be recognized to ask a question via microphone use the hand raising option located above the list of participants (Ctrl R) Emotions/Hand-raising: Please do not use these features during this session unless instructed by the presenter. 3
    • 4. Web Accessibility in the Hospitality Industry Eduardo Meza-Etienne, Senior Account Manager Debra Ruh, Chief Marketing Officer www.ssbbartgroup.comSilicon Valley (415) 975-8000 www.ssbbartgroup.com Washington DC (703) 637-8955
    • 5. Agenda The Hospitality Industry The PwD Market Business Case Managing Accessibility Conclusion 5
    • 6. Hospitality Industry Broad category of fields within the service industry An industry worth several billion dollars Dependent on availability of leisure time and disposable income 6
    • 7. The PwD Market 7
    • 8. The PwD MarketThe Persons withDisability (PwD)community is a viable,growing, emergingmarket, with hundredsof billions of dollars indisposable incomeavailable. 8
    • 9. The PwD Market Market Size Over 1 billion people, or about 15% of the worlds population, live with some form of disability – that’s 1 in 7 people. There are 60 million plus persons with disabilities in the U.S., affecting approximately 1 in 2 Americans “living with” or “directly affected by” these individuals. AARP (Association for the Advancement of Retired Persons) says 4 million Americans turn 50 each year - at age 50, adults begin experiencing age-related physical changes that affect hearing, vision, cognition and mobility. More people living longer will result in a dramatic increase of people experiencing some form of disability at some point in their lifetime. 9
    • 10. The PwD Market Global TravelThe European Tourism 2000 Initiative indicates that outof the 50 million persons with disabilities in Europe,70% have the means to travel.The New York Times reported that spending bytravelers with disabilities exceeds $13.6 billion annually.According to the 2005 study, “Adults with Disabilities:Travel and Hospitality”: • 69% of adults with disabilities (or more than 21 million people) from the US have traveled at least once in the past two years. • Over the course of two years international travel expenditures for travelers with disabilities exceeded $7 billion. • Worldwide travelers with disabilities spent almost $1,600 on each trip. 10
    • 11. The PwD Market Spending Power $220 billion in discretionary income controlled by people with disabilities in the U.S., and $3 trillion worldwide. Persons with Disabilities in the US have an aggregate income of over $1 Trillion dollars, twice the spending power of teens, and more than 17 times the spending power of tweens (8-12 year-olds), the two demographics sought after the most by business marketing efforts. US research by McKinsey & Company predicts that by 2015, the baby boomer generation will command almost 60 percent of net U.S. wealth and 40 percent of spending. In many categories, like travel, boomers will represent over 50 percent of the consumer market. 11
    • 12. The PwD Market Difficulties in TravelSome Current Challenges:Physical access – mobility, vision, hearing - Facilities create barriers to access or enjoyment - Accessibility achieved through accommodations and/or retrofitting existing facilities, often poorly done and in a separate, less convenient locationAttitudinal barriers towards PwD - PwD don`t want to travel, nor are they able to afford it - PwD prefer to travel in groups, and stay close to home - Never seen PwD travelling or at resorts, so why bother - Fear of what to say to PwD – assumptions that they are slow or not able to communicateLack of access to accessible ICT - Reservations systems - Web sites - Kiosks - Online Customer Service Centers 12
    • 13. The PwD Market Difficulties in Travel (cont.)Blind and Vision ImpairedNot enough space in common areas to manoeuver with a caneWhen using a service animal, no place for the animal to relieve itself,or the designated place is in an inconvenient locationPrint on hotel and emergency information, restaurant menus,directions and maps, remotes and other controls hard to read – fonttoo small, poor color contrast, and Braille rarely availableDeaf and Hard of HearingNo open or closed captioning on televisionsRooms do not have door bellsTelephones do not have visual warning when ringing, or regular phones are used instead of a TTY or Video PhoneMobility ImpairedHallways too narrow and not enough space in common areas tomanoeuver with a wheelchair or scooterInaccessible bathrooms , with limited space to move, no handles fortransfer, no roll-in showersMany facilities accessible only by stairs 13
    • 14. Hospitality IndustryBusiness Case 14
    • 15. Business Case Risk of Litigation Litigation risk is the potential costs to an organization from complaints, litigation costs, damages and injunctions Risk from both publicly available systems (ADA Title III) and employee facing systems (ADA Title I) • International law is often more aggressive than US law Organizations face risk roughly correlated to their transaction volume Cost to settle a class action lawsuit including damages and injunctive costs typically tops $10M Contract representations, modifications to products and broad compliance claims can transfer risk to an organization 15
    • 16. Business Case Legal Obligations• ADA – Americans with Disabilities Act• Section 508 of the Rehabilitation Act of 1973• Section 255 of the Telecommunications Act• U.S. Carrier Access Act• HAVA – Help America Vote Act• State Legislation (Section 508 “Type”)• International Legislation (DDA, EU, Section 508 “Type”)• W3C WCAG 2.0 Standards• UN Convention on Rights of Persons with Disabilities 16
    • 17. Hospitality IndustryManaging Accessibility 17
    • 18. Managing Accessibility Successful Accessibility Initiative PhasesOrganizations generally rollout accessibility using a sixstage process:1.Policy Development - Develop the core accessibilitypolicy, target standards and timeline. • Accessibility Policy • Accessibility Issue Resolution Policy • Accessibility Quality Control Plan • Accessibility Monitoring Plan • Procurement and Contracting Policy1.Standards Development – Define the technical standardsand supporting documentation for implementing thestandards. 18
    • 19. Managing Accessibility Successful Accessibility Initiative Phases (cont.)3. Implementation Plan Development – Develop the implementation plan for rolling out the policy and standards across the organization. • System Survey and Analysis • Accessibility Project Management Plan3. Training Development – Develop the training plan, eLearning modules and training courses used to train the various different roles.4. Pilot Implementation – Implement the accessibility standards in key, high risk systems.5. Full Deployment – Deploy the standards and policy across the organization. 19
    • 20. Managing Accessibility Testing Methodology - Requirements for Compliance Auditing Technical Requirements (§1194.21 | §1194.22) • Requires a system to have a conformant technical implementation • Testing requirements are split between those that can be tested Automatically (24.8%), Manually (48.3%) and Globally (26.9%) • Automatic testing is the cheapest and most common testing but covers only a small fraction of legal requirements Functional Requirements (§1194.31) • Requires a system to be usable to people with disabilities using current assistive technologies • Functional testing coverage for sensory and mobility impairments is generally required Support Requirements (§1194.41) • Requires a system to be accessible in deployment 20
    • 21. Managing Accessibility Testing Methodology •Groundwork •Testing •Reporting Identify Analysis Automated Global Manual Modules Prioritization Identify Authoring Assistive Technology Use Cases Delivery Provide a three phase formal testing methodology for determining compliance. For any given project, use a mix of the testing phases and formality that makes the most sense. Focus principally on the testing phase and add and remove requirements as needed. 21
    • 22. Managing Accessibility Tiered Testing Model General teams are responsible for small, targeted sub- set of requirements Internal expert teams are responsible for the full set of requirements Internal expert teams are supported by an external expert Over time organization learns more about accessibility organically versus in one disruptive and expensive push 22
    • 23. Managing Accessibility Tiered Testing Model - Considerations General approach requires specific internal resources to be earmarked for accessibility For internal experts to be active they need to only be working on accessibility issues Approach requires a large amount of education and knowledge transfer for internal experts – this takes time Organizations may find it more effective to outsource some or all of the internal expert work 23
    • 24. Managing Accessibility Tiered Testing Model – Automated Testing Early and often Automatic tests integrated into functional testing system and build environment Addresses many of the low hanging fruit Gold standard of accessibility validation every check-in Good enough standard is validation of accessibility as part of regression functional test script execution As manual testing identifies automatically testable cases add to test definition for future automatic regression 24
    • 25. Managing Accessibility Tiered Testing Model – Manual Testing Considerations Manual tests require extensive subject matter expertise • Many manual tests require the use of assistive technologies, Application Programming Interface (API) monitoring tools or other complex techniques to validate a best practice • Many manual tests require judgment calls on the part of the tester to determine if a item meets the spirit and letter of a requirement • The expertise required to make these determinations is significant • Knowledge maintenance generally requires about a month of research and review a year 25
    • 26. Managing Accessibility Tiered Testing Model – Manual Testing Considerations (cont.) Manual tests are expensive • WCAG A and AA conformance requires testing 177 best practices out of the box of which 133 are manual tests • Validating all 133 best practices across twenty modules (pages) would require 2655 test executions. If we assume thirty seconds per test that translates to twenty-two hours of manual testing per test cycle • Formal audits are expensive and time consuming • Performing full formal audits each QA cycle is cost and time prohibitive • Perform full audits at specific gateways – use informal testing the majority of the time 26
    • 27. Managing Accessibility Tiered Testing Model – Internal Accessibility Testing Define test set based on accessibility policy Develop short list for testing set at 90% coverage point Quick list is validated every sprint or development cycle on limited set of pages • Page test set is traffic ordered pages and high risk transaction paths • Test most common pages first • Basic smoke test Shared client and external team would test full list every three sprints or major release per product Full testing by internal expert team between projects 27
    • 28. Managing Accessibility Tiered Testing Model – Functional and External Functional Testing • Limit functional testing to end cycle acceptance testing • Link limited functional testing to full review of products • Provide functional testing via users with disabilities on-demand at Time and Material Basis External Accessibility Testing Team • Develop accessibility testing team for in-depth accessibility testing • Tests every three to four sprints or major release per project • Accessibility testing team would rotate coverage per sprint across projects • Perform ad-hoc testing on new templates, wireframes and widgets being developed • Consult with development team on questions 28
    • 29. Managing Accessibility Tiered Testing Model – Functional Testing Considerations Different versions of assistive technologies, drastically different results • Assistive technology support for web technologies changes drastically from version to version • Determining if the issue is an issue in JAWS or the AT or an issue of operator error is significant • Signal to noise for false positive and negatives is significant – often exceeding the actual count of valid bugs • Accurate testing results requires intimate knowledge of AT support and control 29
    • 30. Managing Accessibility Tiered Testing Model – Functional Testing Considerations (cont.) Accurate functional testing requires a user with disabilities. To execute functional tests a user must have a high degree of familiarity with assistive technology. For example, testing accurately with screen readers requires that the user: • Never see the page • Never use the mouse • Only control page elements through the screen reader and relevant reading modes In practice, SSB has never seen users without disabilities effectively test in a fashion that provides a meaningful simulation of the experience of a user with a disability. 30
    • 31. Hospitality IndustryConclusion 31
    • 32. Conclusion If Needs Were Met?“24 Million People With Disabilities Would Travel One or Two MoreTimes Per Year, If Their Needs Were Better Met.” -Fortune Magazine 32
    • 33. Conclusion Questions??? 33
    • 34. Next StepsNext Steps Point of Contact Schedule some time to speak with Eduardo Meza-Etienne an SSB expert in your industry SSB BART Group Sign-up for a online training Senior Account Manager covering further topics on  Eduardo.meza@ssbbartgroup.com Accessibility  (202) 600-8932 (o) Contact the industry expert to  (240) 457-8046 (c) setup a free trial of AMP Follow us on Twitter, Facebook and LinkedIn 34

    ×