Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


The Accessibility Team Process

No description

Daniel Watkins

on 26 March 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of The Accessibility Team Process

The Accessibility Team Process
Explaining what we do
We're all familiar with the normal process that's taken with standard Pearson technical support tickets.
However, this is not the same process used for Pearson accessibility tickets! We would like to show you in detail what we deal with while helping accessibility students.
How to Resolve an Accessibility Ticket
Accessibility Testing
Special programs are often used. Sometimes, their tool is not working with our products.
Introduction to Pearson Accessibility Guidelines
Pearson strives to provide accessibility options for people of all walks of life. We value People and Learning.

Our Development Teams are under constant scrutiny to ensure that they are providing full compatibility with a wide variety of Accessibility programs and global medical standards.
Statistics and AHT
But we still need to assist the users that we can. We can't brush off people because we have an AHT.

We try to treat each case individually, since each one is unique.

In addition, we need to follow the Federal guidelines when we respond to student/customer.
Blind or low vision
Deaf or low hearing
Limited vision (color blind or blurred vision such as cataracts)
Any learning Disability
Motor Skills
What does this mean for us?
We have to test using the student's OS and accessibility tools.
We determine the Operating System such as Windows or Mac.
Many times, we need to test in multiple OS' and multiple programs in order to determine the best resolution.
Zoom Text
Window Eyes
Voice Over (Mac)
ChromeVox (Google)
Windows Accessibility Tools
Microsoft Magnifier
High Contrast settings
DPI settings
We as a company are required to comply to the guidelines established by the government and international internet consortiums. These guidelines explain how to:

Make educational Web media accessible to people with disabilities
Meet the international Web content accessibility guidelines from the World Wide Web Consortium, specifically Web Content Accessibility Guidelines Version 2.0 (WCAG 2.0) at Level AA
Meet current US Government Section 508 Standards, specifically § 1194.22 Web-based intranet and internet information and applications
Assumptions for Standard Tickets
Users can navigate to the correct area with minimal assistance.

If Troubleshooting is required, there are limited number of supported applications to handle

The answer is almost always in the KB.
Trust and Rapport
How to Resolve a Standard Ticket
-Standard tickets are solved via

Meaning, if we can replicate, then we Advance/Escalate.

1. We
the browser
2. We
the computer
3. We
to see if the network has a problem.
Let's get started
Now that you have seen the company guidelines regarding Accessibility, lets take a look at how the helpdesk handles tickets in further detail.

First lets take a look at the assumptions we make for a standard Pearson Technical support ticket.
Every User is Unique
Flow of Accessibility Ticket
Problem Solving
Variables that will affect 2015
Projected Volume 2015 will increase
Picked up the accessibility mailbox.
Mostly alternative text.
It think emphasizing the end goal of regular tickets and accessibility tickets and contrasting them could be effective here. I really like the idea of referring to standard tickets as "Troubleshooting" and accessibility tickets as "Problem Solving". Pointing out in the Assumptions for regular tickets that users are "normal" might be a bit redundant. Maybe reorganizing the Standard Troubleshooting and Assumptions for Regular Tickets bubbles. Possibly something like this:

Standard Troubleshooting

*The goal when standard troubleshooting is to identify problems effecting user interaction with our platform. Ultimately this will end by identifying a problem with the platform itself or with software or hardware on the side of the end user. By following the scripted process below we are able to deduce where the issue lies and report it to the appropriate contact.

The situation - if we can replicate, then we escalate.

1.We troubleshoot the browser
2.We troubleshoot Student’s computer
3. We troubleshoot Student’s network

Accessibility Problem Solving

*The goal when providing solutions for an accessibility user is to ensure access to our product in spite of limitations of the user, their hardware, or software being used. We achieve this through the process below.

1. Becoming familiar with the user's limitations.
2. Identifying what assistance is available to the user through their institution.
3. Suggesting and testing possible solutions for the user to find the best fit.

After all of this if a problem persists and we can replicate, then we escalate. However, we still may be in active pursuit of an alternate solution for the user even after escalation. Solving the access problem for the user is paramount.

Let me know what you think.

Graph of amount of contacts handled
- Accessibility tickets are resolved by

Problem Solving

The goal when assisting an accessibility user is to ensure access to our product in spite of the user's limitations, hardware, or software. We achieve this through solving unique problems one by one.

1. Becoming familiar and understand the user's limitations.
2. Identify what options are available to the user.
3. Test and Suggest possible solutions for the user

There are many types of accessibility issues. Every user is unique and has a different set of needs. Below are just some of the more commonly seen situations.
Thus, there is no way to measure AHT due to a number of factors:
Level of disability
Access to Resources
Communication Process
During Peak, we are projecting 22-25 contacts a week.
'Brief' Synopsis of an Accessibility Problem Solving Ticket which took from 9/9 to 10/15
Ticket is about how to highlight text in MyStatlab and have NVDA read to you. It is not working right.
9/9 -
called in about issue. It will allow some areas to highlight but not all. Issue was advanced to the next level. The next level gathered the necessary information for the accessibility team per the accessibility template. Homework is in Flash and cannot be copied. We are trying to use the free options available for the student.
9/10 -
tested in Windows 8 with both NVDA and Windows Eyes
9/11 -
tested in ChromeVox and JAWS 15.
She left a VoiceMail (VM) for the student to advise of ticket number and the hours she can be reached.

called in and asked to be transferred. Michelle is not in. Student gave contact information and best times she could be reached.
9/12 -
tested again with NVDA. The only program that seems to work is JAWS 15.

contacted Donna and advised her to contact DDS. Asked about the disability. We will try more testing on NVDA.
Student will contact DSS
- Heather from QA
tried to come up with solution. It will not read flash at all. Page is not marked up correctly for the screen reader to read it.

emailed back because she is having issue with StatCrunch now. It is overlapping. We emailed
, but they are out until 9/22.
called student with scheduled update and asked about DSS dept. However, left voice mail (VM) and sent email.
9/22 MyMathLab works with JAWS 14 and lower (BTW, JAWS is on version 16).
Suzanne Taylor
advised us to work with
Heijung Kim,
accessibility expert for MyMathLab.
Heijung Kim
advised that it works with IE 9 and XP. They also said Firefox and Chrome will not work.
Heijung Kim
back asking about Windows 8.1 and IE 11. (JAWS 14 and IE 9 are not compatible with Windows 8.1. Michelle called Freedom Scientific about JAWS 14 and Windows 8. It is not compatible. It needs to be JAWS 15. Nothing works with
MyStatLab and StatCrunch.
about the Flash and NVDA compatibility.
is still working with
Heijung Kim.
is awaiting another emai from
Heijung Kim.
9/25 No response yet from student.
called student and left VM.
emailed and said college is working on getting JAWS for her. Student notes that schedules are tight to coordinate via phone so she would prefer email.
emailed student to coordinate time so she could talk to Michelle directly.
emailed us. College installed JAWS, but now the screen magnifier does not work. Student wants to know if MAGic screen magnifier will work.
tested it. It is only working on problems marked as accessible. Michelle explained how to use the Flash section. MAGic 12 is not compatible with Windows 8.1. Advised JAWS will only read one line at a time.
tried to callback the student several times without success. He emailed back student.
emailed back She does not think it is reasonable to require two very expenstive program Student is questioning why? MyStatLab is not accessible with magnifiers? Student said email is the best form of communication for her.
emailed back the student and explained about Flash and the different programs and how they work.
emailed up is asking about why JAWS reads unnecessary things. She said she needed TTS and screen magnifiers.
Keith, supervisor,
advised student to call us rather then emailing us so we could assist her more effectively.
emailed us back stating that she needs MyStatLab in HTML format. She wants the contact information for the President.
emailed student and advised her that we have exhausted all resources.
emailed us back expressing gratitude for the work that we did.
wanted to thank everyone for their assistance and was looking for the contact information.
Bottlenecks and Roadblocks
As you can see,

Accessibility tickets have a large amount of testing that can take more than an hour.
We are the intermediaries between the student and different areas such as QA, and other accessibility teams such as Kathy W, and Elaine.
Bottleneck - we often have to wait until we get an answer from another before we can
Oftentimes, we do the testing. However, we may need to work with development to get issues corrected.
Improvements Made to date
Flow of Standard Ticket Troubleshooting
Requested Alias email, this allow us to get the tickets directly.
We also have a new ACC/PL template
There is now a team dedicated to Accessibility
Revised KBs
Improved KB searches
Spreadsheet with the tickets so we can review the process and see what solved the issue.
Guidelines Expanded
Accessibility Programs
Potential for Improvements
Allow members of the Accessibility team visibility of the Accessibility/Disability queue.
More opportunities for team meetings and trainings, so we can all handle tickets as timely and accurately as possible.

Unfortunately many people with disabilities are looked down upon by other individuals.

Almost all have encountered situations where they needed help, and someone was unwilling to provide them assistance.

This is exacerbated for accessibility students as they have often been passed around various support areas in Pearson or even their school without success.

Hence they are reluctant to share the issue again because of the hassle.

We need to provide them a place where they can get that help. They need to Trust that we can and will assist them.

No matter how long it may take!
This ticket is still ongoing!
For example, the screen reader, JAWS reads the headers of the HTML documents. In order to do that, Pearson has to write the code so that the JAWS will to that. These guidelines dictate how to be in compliance with WCAG 2.0, Section 508 and ADA guidelines.

Find more info here:

Guideline Examples
Full transcript