The document provides an overview of a webinar on web accessibility in the hospitality industry presented by Eduardo Meza-Etienne, Senior Account Manager, and Debra Ruh, Chief Marketing Officer. The webinar covered topics like the hospitality industry, the persons with disabilities market, the business case for accessibility, managing accessibility, and concluded that if the needs of persons with disabilities were better met, 24 million more people with disabilities would travel one or two more times per year.
08448380779 Call Girls In Chhattarpur Women Seeking Men
Web Accessibility in the Hospitality Industry
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 captioned
Silicon 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.com
Silicon 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
8. The PwD Market
The Persons with
Disability (PwD)
community is a viable,
growing, emerging
market, with hundreds
of billions of dollars in
disposable income
available.
8
9. The PwD Market
Market Size
Over 1 billion people, or about 15% of the
world's 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 out
of the 50 million persons with disabilities in Europe,
70% have the means to travel.
The New York Times reported that spending by
travelers 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 Travel
Some 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 – font
too small, poor color contrast, and Braille rarely available
Deaf 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 Phone
Mobility Impaired
Hallways too narrow and not enough space in common areas to
manoeuver with a wheelchair or scooter
Inaccessible bathrooms , with limited space to move, no handles for
transfer, no roll-in showers
Many facilities accessible only by stairs
13
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
18. Managing Accessibility
Successful Accessibility Initiative Phases
Organizations generally rollout accessibility using a six
stage process:
1.Policy Development - Develop the core accessibility
policy, target standards and timeline.
• Accessibility Policy
• Accessibility Issue Resolution Policy
• Accessibility Quality Control Plan
• Accessibility Monitoring Plan
• Procurement and Contracting Policy
1.Standards Development – Define the technical standards
and supporting documentation for implementing the
standards.
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 Plan
3. 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
32. Conclusion
If Needs Were Met?
“24 Million People With Disabilities Would Travel One or Two More
Times Per Year, If Their Needs Were Better Met.” -Fortune Magazine
32
34. Next Steps
Next 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
Notas del editor
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.