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

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.

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.

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.

Hopefully that clarifies why I think this discussion is off-topic for ARIA. I've quoted some relevant portions of the IndieUI Events spec below.

Cheers,
James


Indie UI Events: Goal #2. https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-events.html#intro-goals
"Enable every type of control in these interfaces to be programmatically determinable and controllable by both mainstream and alternate forms of user input."

Indie UI Events: UI Actions. https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-events.html#actions
"Every element may have a uiactions attribute specified, which is necessary to define the receiver of each type of request event. The attribute, if specified, must have a value that is a set of whitespace-separated tokens representing the various actions to which the web application responds on behalf of this element. The actions that an element has assigned to it consists of all the tokens returned when the value of the uiactions attribute is split on whitespace. (Duplicates are ignored.) User agents MUST reflect the uiactions content attribute in the uiactions IDL attribute.
…
User interface actions are declared as enumerated token attribute values on an element. Each value corresponds to a specific UI Request Event, and declares the web page author's ability to receive and handle each of the request events initiated by the user agent. In order to receive each request event, authors must also register for the event using Element.addEventListener() at this node or higher in the DOM. User agents SHOULD NOT initiate a UIRequest Event when the user's point-of-regard is not inside an element with the corresponding defined action."

Indie UI Events: Interface UIScrollRequestEvent. https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-events.html#UIScrollRequestEvent
"Scroll Request (scrollrequest) Initiated when the user agent sends a scroll request to the web application with accompanying x/y delta values or one of the other defined scrollType values. Authors SHOULD only use this event and uiaction with custom scroll views that cannot be acheieved with native scroll views, because the hardware-accellerated scrolling of native views will always outperform these events."


On Apr 28, 2014, at 12:09 AM, Matthew King <mattking@us.ibm.com> wrote:

> Bryan, 
> 
> I agree with the value statements you have provided, but would like to suggest considering an alternative approach of a property aria-scrollable that could be applied to any type of region, document, or article. We may also consider allowing it to be used on grid and the new table role. All suche elements present the same types of issues on small screens and especially with touch interfaces operated via screen reader. 
> 
> This is also similar to the idea that regions can become interactive widgets with the use of aria-expanded -- a design pattern not currently addressed by the specification or authoring practices but one with merit. I can similarly imagine a landmark region that is focusable, expandable, and scrollable. 
> 
> 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/27/2014 12:34 PM 
> Subject:        RE: OT Re: What is the expected behavior of scrollable divs within touch screen  devices, and does ARIA apply? 
> 
> 
> 
> Also, since the next question is likely ‘why’, I figured I would just circumvent it by answering this in advance. 
>   
> Basically scrollable regions are already built into browsers and they work fine from the keyboard when you add tabindex=0 to the scrollable element. All of the visual rendering is handled by the browser as well when offscreen content is recognized and overflow is set using CSS. 
>   
> The problem is that there is no textual equivalent for non-sighted AT users, to convey which area is scrollable or what the platform level commands are for interacting with it. 
>   
> So, if you had an ARIA attribute, such as role=”scrollable”, you could define this functionality and give it a specific name that could be mapped in the accessibility tree via aria-label/aria-labelledby. 
>   
> This would make it possible for platforms to recognize the role, and convey the proper key commands or gestures for AT users when the region receives focus, similar to the way that VoiceOver announces that an element marked up with role=”slider” is a slider, and to swipe up and down to move it. 
>   
> Also, as James N mentioned about voice activation, this would make it possible to use the explicit name of a region to enable scrollability as well, such as saying “scroll viewer down” if aria-label or aria-labelledby referenced the name of the scrollable region as “viewer”, which could be tied into the platform. 
>   
> Obviously there would need to be a way to convey this functionality, like listing scrollable regions so that the names would be recognized, but this too would be doable. 
>   
>   
>   
> From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com] 
> Sent: Sunday, April 27, 2014 9:37 AM
> To: 'James Craig'; 'Matthew King'
> Cc: 'W3C WAI Protocols & Formats'
> Subject: RE: OT Re: What is the expected behavior of scrollable divs within touch screen devices, and does ARIA apply? 
>   
> Thanks, I’m not really sure this is off topic though, because my original question still stands, regarding whether there would be benefit in standardizing a method for defining scrollable regions for ATs. I think this is needed, because there is currently no way to do this reliably. 
>   
> This could be done using ARIA, such as creating a role that conveyed this type of functionality, which could be combined with aria-label to set an explicit label for the scrollable region. 
>   
> Also, the compatibility differences we’ve been discussing are relevant for the ARIA support table we were discussing a couple of weeks back, which I’m still planning a template for. I should be able to send through a sample by the end of next week. 
>   
> From: James Craig [mailto:jcraig@apple.com] 
> Sent: Saturday, April 26, 2014 12:58 PM
> To: Matthew King
> Cc: Bryan Garaventa; W3C WAI Protocols & Formats
> Subject: OT Re: What is the expected behavior of scrollable divs within touch screen devices, and does ARIA apply? 
>   
> [This thread is going well off topic for ARIA standardization discussion, though it may be interesting to discuss some of the points on the IndieUI list.] 
>   
> Bryan and Matt, 
>   
> Did you file bug or enhancement reports as requested with any AT vendor? If so, privately send me the bug numbers for the Apple-related ones, but don’t forget to file relevant bugs against Android, WP, and FFOS, too. 
>   
> 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. 
>   
> As for the screen reader usability of this example, much could be improved for the sighted user interface of this example as well. Desktop design patter paradigms based on keyboard and mouse interaction don’t always transfer well to other modalities, hence the relevance to IndieUI. 
>   
> Be careful to not confuse existing behavior (on any platform or device) with a fundamental incompatibility or limitation. Remember that only a few years ago, most accessibility “experts” assumed touchscreen interfaces would always be completely inaccessible. Never underestimate the power of software and a creative mind. 
>   
> Let’s get back to talking about ARIA 1.1. 
>   
> Cheers, 
> James 
>   
> 
> On Apr 26, 2014, at 5:09 AM, Matthew King <mattking@us.ibm.com> wrote: 
> 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
> 
> 
>