RE: article navigation

Potentially one could change the rotor or other mode selection mechanism by
adding feed forward and backward capability within the context of a feed.
So, rather than say previous/next article do previous/next feed item. The
fact that they are articles should not matter to the user. I would not have
the user switch the mode because that is prone to error which I think you
are eluding to.

Rich


Rich Schwerdtfeger



From: Cynthia Shelly <cyns@microsoft.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS, James Craig
            <jcraig@apple.com>
Cc: "public-aria@w3.org" <public-aria@w3.org>, PF
            <public-pfwg@w3.org>
Date: 12/01/2015 12:45 PM
Subject: RE: article navigation



Our touch navigation uses modes (headings, items, paragraphs, etc.) with
next/previous gestures. I believe the rotor on iOS is similar. One approach
would be to have a mode for feed navigation.  Adding modes doesn’t work
forever, however. When you have too many, switching between them takes too
long and can be confusing. Another would be to leverage an existing mode
like paragraphs, containers or landmarks.

This is a question of AT UI design though, which seems out of scope for
this working group.

From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com]
Sent: Tuesday, December 1, 2015 10:01 AM
To: James Craig <jcraig@apple.com>
Cc: public-aria@w3.org; PF <public-pfwg@w3.org>
Subject: Re: article navigation



So, one of the things we have added is a "feed" role that takes a list of
articles. So, at least in this instance you know that articles within a
feed are part of the feed. The user needs to be able jump between articles
within a feed without and still be able to navigate the contents of each
article. Facebook will be implementing for its infinite feeds. They
implemented these "J" and "k" keyboard commands to navigate among the
articles (you can try it on Facebook). This won't fly in a mobile touch
device so I was hoping we could leverage something you were doing for
articles. ... however if you have suggestions about how that could be done
on a mobile device that would be great.

I have a product team who can already make use of feeds. I am not sure if
you looked at it yet but here it is:

http://www.w3.org/TR/wai-aria-1.1/#feed




Rich Schwerdtfeger

Inactive hide details for James Craig ---11/30/2015 08:56:44 PM---> On Nov
30, 2015, at 11:52 AM, Richard Schwerdtfeger <schwerJames Craig
---11/30/2015 08:56:44 PM---> On Nov 30, 2015, at 11:52 AM, Richard
Schwerdtfeger <schwer@us.ibm.com> wrote: >

From: James Craig <jcraig@apple.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: PF <public-pfwg@w3.org>, public-aria@w3.org
Date: 11/30/2015 08:56 PM
Subject: Re: article navigation





> On Nov 30, 2015, at 11:52 AM, Richard Schwerdtfeger <schwer@us.ibm.com>
wrote:
>
> Hi James,
>
> Does VoiceOver have a gesture navigation capability to move among
articles on iOS?

No. VO has a rotor for landmarks, but article is not a landmark.

Also, are you referring to ARIA's article role, or HTML's <article>
element? IIRC, there was also some concern that the <article> element was
being overused, and a direct 1:1 mapping to the ARIA article role would
result in false positives. We'd need heuristics in the engines to snuff of
the extraneous articles like we have for layout tables and listitis
overuse.

James

PS. "feed" seems a out-of-scope for a 1.1 criteria, does it not? Why is a
list of articles in a feed more or less semantic than a list of article
outside a feed? Does the end user need to know about the difference? If
not, cut it.