W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2015

Re: LasyLoad

From: Mandana Eibegger <mandana@schoener.at>
Date: Wed, 01 Jul 2015 16:37:49 +0200
Message-ID: <5593FB3D.7000509@schoener.at>
To: w3c-wai-ig@w3.org

how about including an extra button "load more items" after the last 
list-item? - this button could be made only visible if you tab to it.
or some appropriate info-element at the end "loading more items - please 

@next loaded item: maybe don't append the new items to the old list, but 
generate a new list which you place below the old list(s)


On 01/07/15 15:28, Batusic, Mario wrote:
> Hi All,
> Lasy load – loading data chunk by chunk is the new art of shoing lists 
> of large data collections such as of search results or posts. Both 
> LinkedIn and Twitter use it. The screen reader users have currently 
> following accessibility barriers where this technique is used:
> 1.By fast tabbing the user reaches the last loaded link in the list 
> and with the next tab the following contents coming beneath the list 
> in the HTML code.
> 2.The user has no possibility to find the next loaded item easily.
> 3.Through these both problems the user is confused – this situation is 
> somewhat similar to automatic scrolling where blind users are also 
> “lost in space”.
> 4.One possibility to solve the problem I think would be the use of 
> list widgets (aria role=listbox) where the developer can implement the 
> keyboard properly and so overcome the loading patchwork. But in most 
> situations there is more than a single link or text entry building a 
> list item. A single search result for example could contain a header, 
> a main link and possibly a paragraph of text following the header, 
> witch could also contain one or more links. That is too much for a 
> simple list widget entry (role=option).
> Can somebody help with a solution? Or do you think the lasyLoad cannot 
> be made accessible? Thanks in advance.
> Mario
Received on Wednesday, 1 July 2015 14:38:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:36:53 UTC