WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Robert Fentress
Date: Aug 30, 2017 5:53PM

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
> > > > >



--
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>