WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Running ChromeVox as a library in a web page?

for

From: Jonathan Avila
Date: Aug 30, 2017 7:26PM

> absent something like this, how you keep moving forward in terms of UI patterns.

Ultimately we need a way to communicate the patterns a control supports, the actions associated with a control, and a method to activate those actions. Instead of solely relying on all sorts of keystrokes if there was a programmatic way to communicate this and perform the actions like those provided through the actions rotor on VoiceOver it would provide consistency and flexibility. Accessibility APIs like UIA support the above at some depth but the ARIA semantics still need to catch up as they are focused on roles and not patterns and there are not great ways of communicated in the DOM the different actions and perform those. Web accessibility will in time be moving into where we can access the accessibility API through JavaScript and these areas will be better supported. The challenge has been up to this point to get the assistive technology and user agents updated to support the current ARIA consistently -- which has taken years to get where we are today.

Jonathan

Jonathan Avila
Chief Accessibility Officer
Level Access, inc. (formerly SSB BART Group, inc.)
(703) 637-8957
<EMAIL REMOVED>
Visit us online: Website | Twitter | Facebook | LinkedIn | Blog
Looking to boost your accessibility knowledge? Check out our free webinars!

The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.

-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Robert Fentress
Sent: Wednesday, August 30, 2017 7:53 PM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Running ChromeVox as a library in a web page?

Thanks for your thoughtful response.

I guess I'm thinking of complex composite widgets where it is not entirely clear what pattern fits, but you want to make sure it's not going to be totally fubar. An example: I've seen a complex autocomplete-like widget, where you are in a field and start typing in characters and a list of users appears in a listbox structure. When you arrow down to select a user and press Enter, a sort of badge appears in the field (or at least appears to be in the field, anyway), indicating you've added that user to a list of users, to be used for whatever process you are trying to accomplish. Then, you can start typing again, bringing up another listbox where you can select another user to be added as a sort of badge in that field, and so on. The badges in the field have little exes in them, allowing you to remove them. It can all be accessed using only the keyboard somehow, but exactly how you structure that in terms of ARIA patterns, and what keyboard interaction model to use is not 100% clear, at least in my mind.

Therefore, what I would want to know, as a conscientious developer, is if this thing--whatever it is--is going to presented in *some sort of sensible
way* to a screen reader user. In cases like this, JAWS may not understand the semantics the developer is trying to express exactly right and present a possibly confusing mishmash of cues and affordances, but VoiceOver may guess what you mean to be conveying well, and so on. It would be helpful in complex cases like this to be able to say something like, "Look, I know this is a weird widget I've made here, but it does provide useful affordances to many users, and I don't want to just stuck be with this limited palette of widgets that the ARIA authoring practices has blessed.
I've tried to use semantics that are proper though, and it doesn't trigger any parsing errors, and I have at least tested this out in ChromeVox and know it works somewhat sensibly there, so if it doesn't work exactly how you'd like it to work with your particular screen reader, you can at least use this in-page screen reader I've provided, and it'll work there."

I know that sucks, and your point about how weird it would be to switch screen readers mid-stream is well taken. It is awkward and probably unrealistic--maybe even a pro-forma copt-out. That being said I guess I'm still confused, absent something like this, how you keep moving forward in terms of UI patterns. This, at least, provides one path that is, to twist the meaning a little, "accessibility supported." Hope that made sense.

On Wed, Aug 30, 2017 at 6:11 PM, Patrick H. Lauke < <EMAIL REMOVED> >
wrote:

> On 30/08/2017 22:36, Robert Fentress wrote:
> [...]
>
>> I've mentioned this before and folks seemed to be baffled by why one
>> would want to do such a thing, but I didn't totally understand the
>> criticism, so I'd appreciate anyone who wished to (kindly) enlighten
>> me. Basically, my thinking is that, if this were an option,
>> developers could code their page or web application to standards, as
>> best they could interpret them, and then test with ChromeVox. If it
>> worked with that, and the developer could, essentially, include that
>> screen reader as an option on the page itself, then it would help
>> ensure at least a floor for screen reader accessibility. It would
>> also provide another option for users, in general, to interact with
>> their site.
>>
>
> This *may* help a subset of users that would require a screen
> reader/AT - mainly those with mild vision impairment, or users that
> with cognitive disabilities who would benefit from self-voicing pages.
> Clearly, any other users that do rely on screen readers would already
> need to have a screen reader installed anyway (in order to log in,
> open the browser, navigate to the site, etc), but of course that's
> also true for ChromeVox itself. But having it installed as extension
> at browser level means that these users still benefit from it on all
> websites, not just on the ones that decided to install some form of
> site-specific ChromeVox library. Also, having it at browser level
> means that users can set their preferences globally, while a
> site-specific version would need it own settings - and then the user
> goes to another site that implements this sort of thing, and the
> settings need to be changed again for THAT site. This then goes into
> the same territory as the discussion around the benefits of site-specific "text resize widgets" versus users actually using text sizing options in their browser...
>
> I think many developers want to do right, but don't have the time to
> learn
>> all the ins and outs of how different screen readers interpret things
>> or to test in a half dozen or more different screen
>> reader/browser/platform combinations, guessing, without any really
>> reliable data, on what those might be.
>>
>
> In general, screen readers interpret well-formed and correctly
> implemented HTML/ARIA stuff fairly uniformly - at least compared to
> years ago. Ideally developers need to learn the "correct" way to mark
> things up (particularly referring to official ARIA patterns) and then
> their sites should work quite well in recent AT. Sure, every AT has
> bugs (the same way every browser has bugs), but the answer to that is
> not to just decide to bless one particular implementation (ChromeVox) as the de-facto standard...
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > archives at http://webaim.org/discussion/archives
> >



--
Rob Fentress
Senior Accessibility Solutions Designer
Assistive Technologies at Virginia Tech
Electronic Business Card (vCard)
<http://search.vt.edu/search/person.vcf?person54847>
LinkedIn Profile
<https://www.linkedin.com/in/rob-fentress-aa0b609?trk=profile-badge>