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:32AM

Sorry, I misread that. Thought you were referring to IndieUI not UIA.

On Thu, Aug 31, 2017 at 11:25 AM, Robert Fentress < <EMAIL REMOVED> > wrote:

> I've *really* gotta make the time to explore UIA. I've heard you mention
> it before and it seemed intriguing, but I just haven't gotten around to it
> yet.
>
> On Wed, Aug 30, 2017 at 9:26 PM, Jonathan Avila < <EMAIL REMOVED>
> > wrote:
>
>> > 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>
>> >> >> 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>
>



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