cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
292
Views
1
Helpful
1
Replies

Webex and Screen Readers - lack of accessibility for notifications

fearthecat
Level 1
Level 1

We're a VoIP provider trying to help one of our customers who supports and employs people with disabilities. One of their staff is vision-impaired (blind) and uses the JAWS screen reader application / adaptive technology.

They use Webex (from Service Providers) version 44.7.0.30285 and receive calls through our VoIP platform either from a Hunt Group or to their direct dial (DDI).

Each call will show a 'toast' style notification in the bottom right of the screen, but these do not seem to be structured the same way as Microsoft Office / Windows 'toast' notifications.

When Webex is the active window, these notifications can be read by JAWS and by Windows Narrator, but when Webex is not the active window, the notifications are not read out by either screen reader application.

Compare this to Microsoft Outlook, and there's a difference - notifications are read by both screen reader applications whether Outlook is the active window or not.

This implies a difference in the way Webex notifications are created/displayed, and represents a lack of accessibility as the employee will only get the ringing tone, with no information about who is calling.

It might seem manageable, but knowing the identity of the caller, or the type of Hunt Group it came from is crucial. Think Sales vs. Support vs. Accounts, or Business Name 1 vs. Business Name 2, or "nuisance caller" vs. "manager".

Unfortunately our platform cannot display the Hunt Group Caller ID in place of the originating caller's number. Both are included in the notification unless the calling number exists in the Webex contacts, where just the name of the contact will be read out (if Webex is active).

We could host a second line (at additional cost) for the employee and configure them to have alternate ring tones, but that lack of announced Caller ID / phone number still makes the employee's job more difficult.

Understandably making Webex more accessible can be a slow development journey. I would be interested in knowing the best route to request feature / accessibility improvements.

Has anyone faced similar issues and found workarounds for them?

1 Accepted Solution

Jonathan Schulenberg
Hall of Fame
Hall of Fame

You can upvote or create an enhancement request on Aha (Cisco/partner/SP and customer). The former allows you to proxy vote on behalf of customers.

I suggest starting with a TAC case though. I’d argue that this should work as part of their existing accessibility capabilities (even better if you’re in a country with a law, e.g. the ADA here in the US) and make them show documentation that it isn’t expected to work. There’s a decent chance this is a bug. If they push back - with supporting evidence - that this is working as designed, you could also make some noise with your Cisco channels team. They should be able to ask the appropriate PM in the BU.

View solution in original post

1 Reply 1

Jonathan Schulenberg
Hall of Fame
Hall of Fame

You can upvote or create an enhancement request on Aha (Cisco/partner/SP and customer). The former allows you to proxy vote on behalf of customers.

I suggest starting with a TAC case though. I’d argue that this should work as part of their existing accessibility capabilities (even better if you’re in a country with a law, e.g. the ADA here in the US) and make them show documentation that it isn’t expected to work. There’s a decent chance this is a bug. If they push back - with supporting evidence - that this is working as designed, you could also make some noise with your Cisco channels team. They should be able to ask the appropriate PM in the BU.