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

On IOS 7.1, the aria-selected="true" is also not revealed.

You can swipe through the content in the scrollable viewing pane, but even 
though the content reads, VO does not scroll it. so, if you touch outside 
the scrollable viewer, you have lost your place.

If VO focus is inside the viewer, a three finger tap always says page 1 of 
1; VO clearly does not recognize the scrollable div for what it is.

Going off topic .... This is the first time I have looked at an ARIA tree 
view with VO in Safari. It really highlights some of the downsides of a 
touch-based screen reader that renders all visual elements. When reading 
by item, you have to swipe through the entire tree. Unlike VO in OSX or 
JAWS, you can't just skip past the tree with a single swipe (equivalent of 
pressing tab. While it is nice to touch anywhere and hear what is visually 
under your finger, e.g., one of the plus or minus signs for expanding and 
collapsing, it is not at all nice if you want to navigate by item. In 
fact, if the scrolled on for a long time, it could be a keyboard usability 
hell.

I think it would be really nice if VO would somehow encapsulate composite 
web widgets like trees, listboxes, grids, and toolbars so there would be 
some single gesture manner for moving past it to the next element. I 
suppose the VO OSX interact and stop interacting concept could be used, 
but that would mean that touching the screen anywhere on that widget would 
have to speak the same thing instead of revealing what is immediately 
under the finger. I guess that would be OK; when interacting the standard 
touch to speak gesture could work. But then there would be the question of 
whether or not it would be desirable for the rest of the screen to not be 
interactive when inside the widget -- that could be both good and quite 
bad..... not an easy set of problems to think out. You wouldn't need any 
new gestures though -- double tap could start interaction and 2 finger 
scrub could stop it. Then, after you have made your tree selection, 
tapping anywhere on the tree would just announce the selected item, tree 
view, and the tree view name .... could be quite nice.

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>, 
Cc:     "'W3C WAI Protocols & Formats'" <public-pfwg@w3.org>
Date:   04/25/2014 08:32 PM
Subject:        RE: What is the expected behavior of scrollable divs 
within touch screen  devices, and does ARIA apply?



Alright, how about this one?
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Trees/Tree%20(External%20XML)/

demo2.htm
Imagine an e-book reader, where, on the left, you have a scrollable index 
of
the chapters that you can scroll through and activate, and to the right of
that, you have a viewer pane where you can read specific chapters or
articles.

E.G The above demo uses an ARIA Tree construct as the index mechanism, and 
a
keyboard accessible scrollable div pane on the right for readers to view 
the
desired scene from Hamlet.

The ARIA Tree is surrounded by a scrollable div that includes 
role="region"
and aria-label="Hamlet, by William Shakespeare - Index", and the 
scrollable
reader pane on the right includes role="region" and aria-label="Viewer".

So, in theory, it should be possible to view this using a mobile device 
like
the iPhone/iPad in landscape mode, tap the Scene that you want to load 
after
expanding the desired Act, then move focus into the scrollable "Viewer" 
pane
on the right, and swipe up and down to review all of the content displayed
there from top to bottom.

With regard to VoiceOver, this appears to expose several bugs, the first
with ARIA Trees, where the expanded/collapsed state via aria-expanded 
within
branch nodes is not conveyed, nor is the level information declared via
aria-level, nor is the positioning information via
aria-setsize/aria-posinset.

Additionally, none of the region information is conveyed, such as the
explicit label for each region via role="region" + aria-label to convey 
its
purpose and where the boundaries are, nor is it possible to swipe up and
down to scroll the viewer content using VoiceOver, at least this isn't
working for me using the iPhone with iOS7.

If anybody would like to try this using an Android with TalkBack to 
confirm
functionality there too, that would be great.

All the best,
Bryan

-----Original Message-----
From: James Craig [mailto:jcraig@apple.com] 
Sent: Thursday, April 24, 2014 11:35 PM
To: Bryan Garaventa
Cc: W3C WAI Protocols & Formats
Subject: Re: What is the expected behavior of scrollable divs within touch
screen devices, and does ARIA apply?

On Apr 24, 2014, at 10:33 PM, Bryan Garaventa
<bryan.garaventa@ssbbartgroup.com> wrote:

> I'm not really sure where this would be handled though, would it be with
the spec, or some spec, identifying a way for browsers to convey a textual
representation exposed by scrollable regions that can be used by ATs, or 
is
it simply a best practice for labeling and defining a region, and is it 
then
up to the AT to ensure support for this even though it's not specified
anywhere?

You could try coming up with an real world example where this is
necessary-make sure you don't make it an contrived test case-and 
submitting
it as a bug report to the various AT vendors. Like all software companies,
AT vendors have a long list of work they intend to complete, and the more
*real* you can make the example, the more likely it is to get a higher
priority fix order. 

James