Re: How Browsers Interact with Screen Readers and Where ARIA Fits in the Mix

Excellent article Bryan
Your article once again highlights the need for a set of commonly adhered
to protocols.
If all browser vendors and AT devices handled the Accessibility APIs in the
same way then developers would be able to code once, and it would work
across all OS/browsers and AT devices.
Kind regards
Harry



On 7 January 2013 07:21, jason@accessibleculture.org <
jason@accessibleculture.org> wrote:

> I was going to comment on your article, but was then faced with having to
> register an account, which I would prefer not to have to do.
>
> However, do feel free, by all means, to add the comment yourself as you
> see fit.
>
> Cheers,
>
> Jason
>
>
> On 7/01/2013, at 8:11 PM, "Bryan Garaventa" <bryan.garaventa@whatsock.com>
> wrote:
>
> Thanks, that is an excellent point.
>
> If you would like to add this as a comment on the article, it would
> probably be helpful to others as well.
>
> All the best,
> Bryan
>
>
> ----- Original Message -----
> *From:* jason@accessibleculture.org
> *To:* Bryan Garaventa <bryan.garaventa@whatsock.com>
> *Cc:* w3c-wai-ig@w3.org
> *Sent:* Sunday, January 06, 2013 10:54 PM
> *Subject:* Re: How Browsers Interact with Screen Readers and Where ARIA
> Fits in the Mix
>
> Hi Bryan,
>
> Good article and an important issue to discuss. The more authors
> understand the basics of how browsers, assistive technologies, and
> accessibility APIs work together, the better.
>
> A few comments:
>
> 1. I think it's misleading, if not incorrect, to say that "All browsers
> that support accessibility, include an accessibility API that is built into
> the browser application." Rather, the accessibility APIs exist at the
> operating system level. That is, they are part of the operating system, and
> a browser makes use of them to varying degrees to expose properties and
> events to assistive technologies, serving as something of an intermediary
> between the browser and assistive technology. The APIs are not "built into
> the browser" per se. This is why, for example, using something like JAWS or
> NVDA with Chrome does not provide the accessibility support that exists
> when using the same screen reader with Firefox or Internet Explorer: Chrome
> does not yet use the accessibility APIs to expose as much information as do
> the other two browsers, although it is improving.
>
> 2. Applications like screen readers tend to retrieve information about a
> web page's content, structures, and relationships by relying on the
> accessibility API and the information the browser passes using that API.
> But screen readers can also query the DOM directly, bypassing the API.
> NVDA, for example, in some cases queries the DOM directly when running with
> Internet Explorer.
>
> 3. Firefox in Windows is beginning to make use of UIA in addition to MSAA
> and IA2. Some of this UIA implementation will make use of IAccessibleEx
> (also called UIA Express), which allows browsers that use MSAA to
> supplement the info they provide via the API with additional UIA properties
> and control patterns.
>
> Best regards,
>
> Jason
>
>
>
> On 7/01/2013, at 5:55 PM, "Bryan Garaventa" <bryan.garaventa@whatsock.com>
> wrote:
>
> In case it's of interest.
>
> The differing behaviors of screen readers across various browsers are
> noticed all the time by screen reader users, and differing levels of ARIA
> support
> are noticed in a similar manner, but the reasons why this happens aren’t
> commonly understood by the majority of people.
>
> For example, the most widely used screen reader, JAWS, is hard coded to
> work best in Internet Explorer. The second most widely used screen reader,
> NVDA,
> is hard coded to work best in Firefox. This includes ARIA support.
>
> Here is the reason why...
> Full article: https://www.ssbbartgroup.com/blog/?p=1734
>
>
>
>
>