- From: Matt King <a11ythinker@gmail.com>
- Date: Wed, 2 Dec 2015 17:34:55 -0800
- To: "'Cynthia Shelly'" <cyns@microsoft.com>, "'Richard Schwerdtfeger'" <schwer@us.ibm.com>, "'James Craig'" <jcraig@apple.com>
- Cc: <public-aria@w3.org>, "'PF'" <public-pfwg@w3.org>
- Message-ID: <067201d12d6a$d0f55f60$72e01e20$@Gmail.com>
Oh, and action 1724, which I will be posting about very soon will also help address some of these. From: Cynthia Shelly [mailto:cyns@microsoft.com] Sent: Wednesday, December 2, 2015 3:30 PM To: Richard Schwerdtfeger <schwer@us.ibm.com>; James Craig <jcraig@apple.com> Cc: public-aria@w3.org; PF <public-pfwg@w3.org> Subject: RE: article navigation There are actually a lot of lists that are infinite or long enough to have the same user experience issues. Email inbox Social media feed Database query results Search results Calendar in agenda view (list of appointments going off into time) Newsfeed (e.g. flipboard) A blog with a lot of posts There are some related scenarios that are infinite/huge but have slightly different behavior, that we've been talking about as part of script-based accessibility: Spreadsheet Large document (word, pdf): pages, long bullet list, outline Presentation slides (powerpoint): slides I'm starting to think that we need a general solution to this problem. Maybe a role can cover the first group, but I'm not sure feed is the right name for it. Many of these have article children, but not all do, and there are likely other infinite lists that I haven't thought of, with different kinds of children. From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com] Sent: Wednesday, December 2, 2015 9:07 AM To: James Craig <jcraig@apple.com <mailto:jcraig@apple.com> > Cc: public-aria@w3.org <mailto:public-aria@w3.org> ; PF <public-pfwg@w3.org <mailto:public-pfwg@w3.org> > Subject: Re: article navigation As was stated before lists are navigated using a standard input mechanism. These are static. Also, lists don't typically have an infinite stream of list items which a feed would have. Tabbing does not work either as you end up landing on embedded links. A feed should also have additional input mechanisms to go home or end. I don't agree that an article should ever be a landmark. I don't want to bring up a list of a 1000 landmarks on a page. This is why I have always argued about having them being a landmark. In the case of a Facebook or Twitter Feed the list could be enormous. Rich Rich Schwerdtfeger James Craig ---12/01/2015 04:06:44 PM---> On Dec 1, 2015, at 10:01 AM, Richard Schwerdtfeger <schwer@us.ibm.com <mailto:schwer@us.ibm.com> > wrote: > From: James Craig <jcraig@apple.com <mailto:jcraig@apple.com> > To: Richard Schwerdtfeger/Austin/IBM@IBMUS Cc: public-aria@w3.org <mailto:public-aria@w3.org> , PF <public-pfwg@w3.org <mailto:public-pfwg@w3.org> > Date: 12/01/2015 04:06 PM Subject: Re: article navigation _____ On Dec 1, 2015, at 10:01 AM, Richard Schwerdtfeger <schwer@us.ibm.com <mailto:schwer@us.ibm.com> > wrote: 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. Why does the user need to care about that? Seems like main > article or list > listitem would suffice. The user needs to be able jump between articles within a feed without and still be able to navigate the contents of each article. This is a case for making article a landmark, whether or not it's in another type of container role. 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> http://www.w3.org/TR/wai-aria-1.1/#feed I looked at it. I don't see a compelling case for feed > article over just loose articles in the page or main... James Rich Schwerdtfeger James Craig ---11/30/2015 08:56:44 PM---> On Nov 30, 2015, at 11:52 AM, Richard Schwerdtfeger < <mailto:schwer@us.ibm.com> schwer@us.ibm.com> wrote: > From: James Craig < <mailto:jcraig@apple.com> jcraig@apple.com> To: Richard Schwerdtfeger/Austin/IBM@IBMUS Cc: PF < <mailto:public-pfwg@w3.org> public-pfwg@w3.org>, <mailto:public-aria@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 < <mailto:schwer@us.ibm.com> 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.
Attachments
- image/gif attachment: image001.gif
Received on Thursday, 3 December 2015 01:35:31 UTC