Re: ARIA and mainstream UI (was RE: ARIA 1.1: Deprecate @aria-grabbed and @aria-dropeffect)

The issue is that user agents have a lot of issues to contend with wrt.
their UI. They may introduce new interaction models or different layout
paradigm shifts. If we start specifying user agent behavior it handcuffs
them.

However, should a host language or browser decide to leverage ARIA (which I
think would be wise in some cases) to provide a better user experience then
that is where the UI should be decided.

This is why ARIA neither requires or forbids user agents from enhancing
native presentation and interaction behaviors.

Rich

Rich Schwerdtfeger



From: Sailesh Panchang <sailesh.panchang@deque.com>
To: John Foliot <john.foliot@deque.com>, James Craig
            <jcraig@apple.com>
Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, Bryan Garaventa
            <bryan.garaventa@ssbbartgroup.com>, Chaals McCathie Nevile
            <chaals@yandex-team.ru>, Joanmarie Diggs <jdiggs@igalia.com>,
            lwatson@paciellogroup.com, "WAI Protocols & Formats"
            <public-pfwg@w3.org>, w3c-wai-ig@w3.org
Date: 09/18/2015 10:08 AM
Subject: Re: ARIA and mainstream UI (was RE: ARIA 1.1: Deprecate
            @aria-grabbed and @aria-dropeffect)



John,

        "The WAI-ARIA specification neither requires or forbids user
agents from enhancing native presentation and interaction behaviors on
the basis of
WAI-ARIA markup.
SP:I interpret "changing the UI" as visual changes to the UI.
Surely ARIA MUST not make visual changes ... that is the prerogative
of  the content authors or user agents / AT.
ARIA primarily helps by exposing role, state, name  to accessibility
API available to user agents including adaptive technologies.

Now the above sentence you quote means, "Browsers may or may not
introduce special presentation to make ARIA-landmark region visually
discernible" like they do for headings, lists, fieldsets etc by
default.

"Mainstream user agents might expose WAI-ARIA navigational landmarks
(for example, as a dialog box or through a keyboard command) with
the intention to facilitate navigation for all users. User agents are
encouraged to maximize their usefulness to users, including users
without disabilities".

SP: This is an illustration of how browsers may exploit ARIA markup to
make content available to users. If browsers start doing this, then
the mechanism provided by screen readers becomes redundant. Screen
readers have taken the lead in exploiting what is exposed by ARIA in
order to make content accessible to their constituents. Browsers
enable AT to exploit the ARIA markup but browsers have not gone all
out to do it themselves.
On the desktop there are several keyboard shortcuts for doing tasks
like maximizing a window or copy/paste. Screen readers do not
ordinarily provide keys to do these tasks but list or point to these
features provided by the OS. Screen readers will do the same if
browsers incorporate mechanisms to expose content marked up with ARIA.
When they do this they will most likely include some visual cues to
indicate presence of ARIA markup they support.

With regard to captions : This an accessibility feature that permits
captions to be shown / not shown based on user's needs.
With regard to Dragon or modifications made by screen magnification
s/w or links list provided by screen reader s/w: That is what AT does
in order to make content accessible. Changing the UI is in fact a
significant part of the accommodation strategy offered by AT to their
users.

Conclusion:  browsers can exploit ARIA to make content accessible to
non-AT / screen reader users too. ARIA is certainly not meant only for
 non-sighted users. I remember early ARIA-examples that made content
keyboard-operable but screen readers were still catching up and  those
examples did not work well for screen reader users.

Best wishes and kind regards,
Sailesh Panchang


On 9/17/15, James Craig <jcraig@apple.com> wrote:
> This has been in since the beginning.
>
> "Aside from using WAI-ARIA markup to improve what is exposed to
> accessibility APIs, user agents behave as they would natively."
>
> http://rawgit.com/w3c/aria/master/aria/aria.html#ua-support

>
>
>
>
>> On Sep 17, 2015, at 11:22 AM, John Foliot <john.foliot@deque.com> wrote:
>>
>> jcraig@apple.com wrote:
>>>
>>> Also, ARIA is not supposed to affect mainstream UI, and your suggestion
>>> breaks that pattern.
>>
>> Hi James, All,
>>
>> I have heard this assertion stated that way before, and I would like to
>> know the history of that thinking, as when I read through all of the
ARIA
>> documentation at the W3C, that idea does not seem to be explicitly
>> expressed, and in fact I can find passages that allude to the contrary.
>>
>>    "WAI-ARIA, the Accessible Rich Internet Applications Suite,
defines a way
>> to make Web content and Web applications more accessible to people with
>> disabilities. It especially helps with dynamic content and advanced user
>> interface controls developed with Ajax, HTML, JavaScript, and related
>> technologies."
>> (source: http://www.w3.org/WAI/intro/aria.php)
>>
>> Focusing on "advanced user interface controls", I absolutely agree that
>> for blind users that statement directly suggests a non-visual solution
>> that screen-readers will both announce and interact with. The addition
of
>> ARIA, and the overall general uptake of ARIA to-date has been a huge
boon
>> for non-sighted users, but, is that the only target audience for ARIA?
The
>> intro states "people with disabilities", not "people who are blind", and
>> so by my reasoning and extension, ARIA *should* also benefit other
>> user-groups within the larger definition of "people with disabilities".
>>
>>
>>    "WAI-ARIA addresses these accessibility challenges by defining
how
>> information about this functionality can be provided to assistive
>> technology. With WAI-ARIA, an advanced Web application can be made
>> accessible and usable to people with disabilities."
>> (source: http://www.w3.org/WAI/intro/aria.php)
>>
>> "... defining how information about this functionality can be provided
to
>> assistive technology..." - there are many AT tools that affect the
>> mainstream UI, to the benefit of end users. Screen magnifiers routinely
>> change the UI (sometimes by over-riding color pallets/choices); tools
such
>> as Dragon, when used to navigate a webpage will "add" visual focus
points
>> on demand, and more mainstream accommodation strategies, found both on
the
>> web and in other meat-space examples, also make adjustments to the
>> "mainstream UI" (consider Closed-Captions as a user-setting change to
the
>> UI).
>>
>>
>> The stated technical goals for WAI-ARIA are:
>>
>>    "...WAI-ARIA provides a framework for adding attributes to
identify
>> features for user interaction, how they relate to each other, and their
>> current state. WAI-ARIA describes new navigation techniques to mark
>> regions and common Web structures as menus, primary content, secondary
>> content, banner information, and other types of Web structures. For
>> example, with WAI-ARIA, developers can identify regions of pages and
>> enable keyboard users to easily move among regions, rather than having
to
>> press Tab many times.
>>
>>    WAI-ARIA also includes technologies to map controls, Ajax live
regions,
>> and events to accessibility application programming interfaces (APIs),
>> including custom controls used for rich Internet applications. WAI-ARIA
>> techniques apply to widgets such as buttons, drop-down lists, calendar
>> functions, tree controls (for example, expandable menus), and others."
>> (source: http://www.w3.org/WAI/intro/aria.php)
>>
>> Now, maybe it's just me, but nowhere within that statement do I see it
>> expressly stated that ARIA cannot effect change to the "mainstream UI" -
>> don't get me wrong, by default I support that idea as a default setting,
>> but there is a middle ground that seems to be being ignored here:
end-user
>> control.
>>
>> Returning to the example of Closed-Captions: clearly, when Closed
Captions
>> are "turned on", they make a change to the user interface - there is now
a
>> text box on top of the video region that was not originally there. By
>> default, most Closed-Captions however are *not* shown: the default is
that
>> they are "turned off".
>>
>> Then there is Dragon: Saying CLICK LINK will place numbered markers at
all
>> text hyperlinks on the visible webpage so that the end user can select a
>> specific link "by number" - clearly this too is a "mainstream UI"
change,
>> this time one that is being applied by the Assistive Technology in
>> question (is Dragon AT?) when it over-lays the numbers.
>>
>>
>> However, the most contradictory information I could find at the W3C that
>> questions your assertion was this:
>>
>>    "The WAI-ARIA specification neither requires or forbids user
agents from
>> enhancing native presentation and interaction behaviors on the basis of
>> WAI-ARIA markup. Mainstream user agents might expose WAI-ARIA
navigational
>> landmarks (for example, as a dialog box or through a keyboard command)
>> with the intention to facilitate navigation for all users. User agents
are
>> encouraged to maximize their usefulness to users, including users
without
>> disabilities. "
>> (source: http://www.w3.org/TR/wai-aria/complete#ua-support_header)
>>
>> Right there, in black and white, it says "...neither requires or
forbids",
>> which therefore leaves open the door that changes to the default UI
*can*
>> be impacted by the use of ARIA, and it further opens the door that
>> suggests that this may in fact be a Good Thing (TM). That statement also
>> indicates that "Mainstream user-agents" could indeed make UI changes to
>> "...facilitate navigation for all users", and frankly I think that
making
>> ARIA more "mainstream" for all users would be a huge win: at times it
>> still feels that ARIA is the accessibility ghetto, the exclusive domain
of
>> screen reader software - a position that I personally find troubling.
>>
>> For these reasons, I bristle just a bit when we are absolutist in the
>> notion that ARIA "...MUST NOT (RFC 2119) make changes to the Mainstream
>> UI" - I am significantly closer to "ARIA SHOULD NOT (RFC 2119) change
the
>> default UI without user-intervention", but I also reserve the concept
that
>> for some users, changing the UI is in fact a significant part of their
>> accommodation strategy, and if/when ARIA can positively assist in that,
we
>> should embrace, not shun, that ideal.
>>
>> Like many of us, I've been around the block a time or two, and I
>> absolutely understand how we need to work *with* the design community,
and
>> not against them by imposing strange rules and requirements that they
>> struggle to understand, never mind artfully integrate, but again, the
end
>> user MUST (RFC 2119) have a direct impact on how they can configure
*their
>> rig* to provide accommodations to their needs. If a combination of ARIA
>> and AT user-interface changes accomplishes that feat, we are winning.
>>
>> Conclusion:
>> Stating categorically that ARIA must never have an impact on the UI
seems
>> to be counter-productive, and I would suggest that if that requirement
is
>> explicitly stated somewhere in the ARIA documentation today, that we
>> should re-open that discussion, with a goal of better fine-tuning
>> (wordsmithing) what is really meant (if, in fact, there is agreement on
>> *that* point).
>>
>> Thoughts?
>>
>> JF
>> ​--
>> John Foliot
>> Principal Accessibility Strategist
>> Deque Systems Inc.
>> john.foliot@deque.com
>>
>> Advancing the mission of digital accessibility and inclusion
>>
>>
>>
>>
>
>
>