RE: OT Re: What is the expected behavior of scrollable divs within touch screen devices, and does ARIA apply?

"Bryan Garaventa" <bryan.garaventa@ssbbartgroup.com> wrote on 04/28/2014 
10:59:48 PM:
> Back to my original question though, which I’ll rephrase to 
> hopefully make it clearer, what is the expected behavior supposed to
> be when an explicitly named region/landmark is declared within a 
> touch screen device? More specifically, is this information supposed
> to be conveyed to non-sighted AT users of that device? How does a 
> non-sighted user know where there is an explicitly labeled region/
> landmark on a page within a touch screen device? This is what I was 
> hoping to get an answer to, and the question is not platform, 
> browser, or AT specific.

If you are asking about expectations conveyed by the the WAI-ARIA 
specification, they are the same for all devices on all platforms with any 
kind of interface. That is, the specification does not tell any user agent 
exactly what to reveal to the end user or how to reveal it. The 
specification stops at the level of the accessibility API for that 
platform. It specifies what should be in the accessibility tree and what 
events should be triggered. But, it is left to the developers of user 
sagent and assistive technologies to decide how their users will benefit 
from that accessibility information.

That scope limitation for WAI-ARIA 1.0 was necessary to get it done. Now, 
as many of us are finding out, there are many cases where some additional 
direction, if not normative requirements than informative guidance, is 
really needed for UA and AT developers.

For now, you must appeal to reason.

VoiceOver does let you navigate by landmark region and informs you when 
the focus crosses a region boundary. However, it does not have a "where am 
I" gesture that enables you to know where the focus is on the screen and 
whether that focus is inside of a region. The suggestion I submitted to 
them is that 3-finger single tap should be extended to do that. Since the 
boundaries are not rendered on the screen, it would be rather difficult to 
enable them to be found with direct touch. Although, I can imagine it 
being done.

Matt King
IBM Senior Technical Staff Member
I/T Chief Accessibility Strategist
IBM BT/CIO - Global Workforce and Web Process Enablement 
Phone: (503) 578-2329, Tie line: 731-7398
mattking@us.ibm.com



From:   "Bryan Garaventa" <bryan.garaventa@ssbbartgroup.com>
To:     "'James Craig'" <jcraig@apple.com>, Matthew 
King/Fishkill/IBM@IBMUS, 
Cc:     "'W3C WAI Protocols & Formats'" <public-pfwg@w3.org>
Date:   04/28/2014 11:01 PM
Subject:        RE: OT Re: What is the expected behavior of scrollable 
divs within touch  screen  devices, and does ARIA apply?



Thanks, I’ll try to answer inline.
 
From: James Craig [mailto:jcraig@apple.com] 
I think you two are still confusing an existing usability issue with some 
relationship to ARIA where none exists. Let me state a few things about 
this conversation as I understand them.

1. Bryan is concerned that iOS sometimes does not convey enough context 
when interacting with divs using "overflow: scroll." This is a valid 
concern that should be filed as a specific issue at bugreport.apple.com. 
It does related to both HTML and CSS, but does not seem to be a bug in 
either. The view is programmatically determinable to be scrollable, so 
this is likely just a usability bug in one specific user context. If 
similar issues apply to other systems, those should be filed as individual 
reports as well.

BG: No, my original question is not specific to iOS or VoiceOver, but 
rather, how to convey context within explicitly named regions. iOS and VO 
was dragged into it because I couldn’t get anybody to understand what I 
was describing without a specific example to demonstrate it. I agree that 
some of these issues are specific to VO, such as the ARIA Tree issues 
described, and some issues with swiping through scrollable content that 
don’t work when VO is running and do when VO is not. I’ll file bugs 
regarding these as soon as I have the chance.

Back to my original question though, which I’ll rephrase to hopefully make 
it clearer, what is the expected behavior supposed to be when an 
explicitly named region/landmark is declared within a touch screen device? 
More specifically, is this information supposed to be conveyed to 
non-sighted AT users of that device? How does a non-sighted user know 
where there is an explicitly labeled region/landmark on a page within a 
touch screen device?

This is what I was hoping to get an answer to, and the question is not 
platform, browser, or AT specific.

If the answer is nothing, and that this is impossible to convey using ARIA 
via a declared role such as region and an explicit label, and there is no 
intention of supporting this type of functionality in the future, then 
entering a bug against the AT will be pointless.

From: James Craig [mailto:jcraig@apple.com] 
2. Bryan and Matt have suggested additional roles or attributes relating 
to scroll views. That is a legitimate "on-topic" discussion for ARIA, but 
it was previously dismissed for several reasons, the primary one being 
that it does not gain us anything. ARIA roles and attributes do no affect 
mainstream user agent behavior, so declaring this was a scroll view would 
be redundant on native scroll views like this div, or entirely pointless 
on custom scroll views.

BG: I understand, but the assumption that I was suggesting behavioral 
changes is incorrect. I understand the reasoning against, however the gain 
of conveying a textual equivalent that simply identifies a scrollable 
region is still valid, and without which, is impossible for non-sighted 
users to recognize within a touch screen UI, because nothing is auditorily 
conveyed as a “scroll view” on any of the devices I’ve tested on. If this 
information is supposed to be conveyed through an AT, that’s great, and 
I’ll file a bug, but I can’t find where this is documented if so.

If it is not desirable to convey this explicitly with a dedicated role or 
attribute, I understand, but I don’t agree that it gains nothing. 

At the very least, it should be possible to use the currently existing 
region role and to set an explicit label that will be conveyed to AT 
users, which leads me back to my original question.

From: James Craig [mailto:jcraig@apple.com] 
3. The reason I stated this was off-topic for ARIA but on-topic for 
IndieUI is because scrolling is one of the primary use cases of the Events 
module. IndieUI Events defines both a declarative way to make custom 
scroll views determinable via uiactions="scroll" but it also allows that 
custom scroll view to be programmatically scrollable, which is something 
that ARIA cannot do. Scrolling and other custom behaviors are a 
non-starter with ARIA, but we're trying to solve that problem using a more 
robust approach.

BG: That’s great, and I don’t see the point of reinventing the wheel 
either. Nevertheless, my question had to do with simply conveying a 
textual equivalent for a region, and nothing more.