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
<http://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.