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 31, 2017 9:19AM

Yes. I suppose there is always a way to decompose things to better fit
existing prescribed patterns. However, we all exist in a practical
context. It is not always possible to prevail upon people we are dealing
with that they need to completely redesign their UI, especially if it was
not the result of the whim of some overly creative developer, but, rather,
involved quite costly usability testing that just didn't happen to include,
in its sample of participants, screen reader users. Working in a
competitive environment where companies are always trying to distinguish
themselves by providing a more fluid experience--for some users at
least--means sometimes one needs to make what is already there work as best
it can, and encourage the building of a culture moving forward that
considers a broader set of users when making design decisions.

On Thu, Aug 31, 2017 at 9:48 AM, Lovely, Brian (CONT) via WebAIM-Forum <
<EMAIL REMOVED> > wrote:

> Oh, the weird widget. That pernicious little stinker whose purpose is just
> what exactly? I assume these hybrid monsters are created to combine two or
> three user steps into one. But at what cost? At what point does the
> confusion of a singleton widget that no sighted user has ever encountered
> and that can only be communicated to screen reader users with great
> difficulty (and the same excessive effort goes into making it keyboard
> accessible) offset the questionable value of a cool looking widget that
> combines three steps into one?
>
> -----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>
> > > at http://webaim.org/discussion/archives
> > >
> The information contained in this e-mail is confidential and/or
> proprietary to Capital One and/or its affiliates and may only be used
> solely in performance of work or services for Capital One. The information
> transmitted herewith is intended only for use by the individual or entity
> to which it is addressed. If the reader of this message is not the intended
> recipient, you are hereby notified that any review, retransmission,
> dissemination, distribution, copying or other use of, or taking of any
> action in reliance upon this information is strictly prohibited. If you
> have received this communication in error, please contact the sender and
> delete the material from your computer.
> > > > >



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