<Lauriat> scribe chuck:

<Lauriat> scribe: chuck

<Lauriat> Rossen: Good afternoon

<Lauriat> Rossen: let scribe know your name. Quick intros

<CharlesL> scribe: Lauriat

Rossen: I'm with microsoft.

<Rossen_> Rossen Atanassov, Microsoft

Janina: chair

Alice: Google

<melanierichards> Melanie Richards, Microsoft

<aboxhall_> Alice Boxhall, Google, TAG

<rakina> Rakina, Google

<joanie> Joanie Diggs, Igalia

<achraf> Achraf Othman, Mada Center

<mhakkinen> mark hakkinen - educational testing service (ets)

Rossen: I want to gather everyone here to talk about the issue of enabling assistive tech to work with virtualized content outside of client.
... What I mean is there are a lot of common patterns on the web, not news to anyone.
... Most apps that are doing things at scale tend to virtualize large parts of content and deliver smaller view. For example
... Social media like facebook, lower content down to cell phone, and others.
... Probably described well, large content on server side, presented view on client that will make AT think it's the totality of content.
... A different pattern is dynamically loaded content for performance reasons.
... Content kept on server side, optimized for client side. Good thing to do. But from AT observes the smaller number of pages.
... ATs are aware of realized content pushed down to user agents creating dom layout and accessibility tree.
... Headings (for example) narrator will read headings and say there's no more headings, no more content.
... If user scrolled down one page, there should be a heading.
... If you look through various posts I'm showing a webim screen reader server. #2 request reads <reads content>
... That's exactly use case for this pattern.
... When we thought of how to approach the solution on browser side it was a little bit daunting to approach the complexity of the web, number of patterns how things are fetched.
... with libraries and what not, in order to make something possible that will solve this problem we came up with a few principals that hopefully if satisfied will allow content to become accesswible.
... 1) Authors of web content should have minimal effort to implement solution.
... ...we've tried with internal partners when working on different ways to approach this...
... When something needs to change in business logic it becomes end of discussion.

2) AT's should be able to continue to innovate. This pattern shouldn't hold them back.

3) Authors and web developers shouldn't be able to observe or fingerprint an AT.

Rossen: As the title says, proposal is that we will introduce an attribute called "aria-virtual-content"
... That simply is an indicator to AT that the content currently presenting through AT to end user is not all of it. There's more content on the server side.
... If we think about the case of headings for example. More often than not the AT will build collection by fetching info from browser (injecting themselves)
... or in other cases where not permissive they will go through system api and build their own structure.
... There is this duplicated data in the browser and AT and what is presented to the user. When they start innovating and allow different modes of operation
... They assume that everything they have in current accessibility tree is all of it. They have 4 headings for example.
... User says "navigate through headings", a collection will be created (four elements inside).
... On last one, user hits next, the AT will say no more items.
... So this is where the aria-virtual-content comes into play. The author managing the HTML and dom side can say "by the way, in that container"
... is used for virtual content. At some point more stuff will be added. Don't assume everything you have (the 4 headings) are all of the headings, there might be more.
... We are allowing authors to say there is more content.
... They have no idea if there's an AT, and they shouldn't. From AT point of view. Once AT realizes it's in this container, as it navigates through headings, when the end is reached...
... I can get the size and scroll that into view, more or less what the guidelines are asking ATs to do anyways. As they scroll a cool thing happens.
... When you scroll down the content, you are triggering a pattern. When I as a sighted user goes to facebook, I scroll down and a script is triggered
... More content is generated and displayed. Same things happen if I have a document and I don't know where the next heading is. For the time being I'm not considering cases such as TOC.
... If Word online wants to create a table of content and triggers that's already possible. We are going after the generic case.
... When we started thinking about this, as the scroll fetches more content, if the author is nice they could realize that they are loading content and add aria-live region and inform the user.
... The AT will have larger collection of headings.
... In order to demo, I have a private build of chromium.
... In my VM... pray to demo gods.
... Any questions so far?

Alice: How do we interpret the values to virtual content. block-start block-end for example.

Rossen: Current proposal...
... Things got interesting here. Current proposal... linking to explainer. When we were experimenting with different applications and how to understand patterns of AT fetching content
... And trigger loading events. The first solution that we had was sort of a binary. You HAVE content or you do not. AT can start scrolling until they fetch more content.
... The other value was NOT. Or remove attribute all together. The more we experimented the more it was prominent that it's better to have...
... more information as to where in the virtual ... or paging application such as google docs, do I have any virtual content for example in the back of my scroll timeline or forward.

<jcraig> WICG link Rossen mentioned: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/Accessibility/VirtualContent/explainer.md

Rossen: The values in the current proposal mapping to css concepts where we say in a scroller theres a block direction that's forwards and one that's backwards.

<jcraig> http://discourse.wicg.io/t/proposal-new-aria-virtualcontent-attribute/3881

Rossen: The need to trigger a forward scroll or a back scroll to load more content. If we think through the word scenario. As I fetch more pages...
... I'm de-virtualizing content in the past. I need to be able to say that there is more virtual content in the reverse direction. That worked fine.
... Then we talked with other partners. They said "that's useful, but we have columns in the horizontal direction, and we need to tell the user".
... As we did this now we enabled this sort of 2 dimensional virtual awareness to say that I have content top/bottom/right/left.
... We aren't married to the conventions. It gets a little better. The more we talked about it with early adopters to the prototype
... The more we found a different pattern. How about... you as an app developer. You know if you have any content of that type. Content authors
... Understand what content they have. That's where playing with the value set becomes interesting. We can be more specific if we want to in the future.
... Maybe there are more headings forward.
... More questions?

<Zakim> alastairc, you wanted to ask Does it rely on a user scrolling? Lot of AT users wouldn’t use scrolling to move down.

Alastair: Sort of getting answer from the link James posted... does it require the user to scroll?

Rossen: It does not.
... Normal use case is we are in a textual document with number of headings and info. Normal AT pattern is if you navigate buy heading...
... When the user moves to next item, they will do so internally, and scroll into view in the element inside the browser.
... The heading will be in view and it will also be announced. There could be a lot of paragraphs until the next heading. More often than not the trigger to load content will be towards the end of the fetch content.
... If I know there are more headings, I have an element that says I have more content, that will trigger normal javascript to load more content. A sighted user will do this, grab scroll bar or fling on touch
... Hit bottom of content, and trigger the load.

Alastiar: That's how AT deals with it today.

Rossen: AT will have to optimize the experience. We don't want to dictate how it's done.

<jcraig> Q

Alice: As a first pass for what the user experience might be, the user would get the ... depends on AT, the user would go next heading, and they would not be told it's last heading, they could do next heading again.
... It will continue...

Rossen: If AT want's to say "heading 1 of 5" that's up to them, knowing they are in virtual content and not knowing how many headings are ahead. I prefer they don't know how many headings there are.
... Facebook for example, never ends.

<Zakim> Lauriat_, you wanted to ask about scroll container delegation and other considered triggering mechanisms.

Alice: You could have gotten to end of content.

Shawn: You answered 2nd question, scroll deligates. You mentioned spreadsheet as example, 2 dimensions of scrolling.
... Google's spreadsheet... it's rendered completely off screen. If you fire scroll events on points of focus, nothing will happen. Need to trigger a deligate.

Rossen: I described one pattern, a container of all headings. But could be a sibling. You can add wherever in the app layer.
... ...and I'm expecting same chain of events to happen.

Shawn: Any other mechanisms considered for triggering the loading of content?

Rossen: I want to have this meeting here and listen to what other types of events are common to make this successful. What are other patterns we can use
... To allow an AT to trigger the load logic.

Shawn: Wracking my brain. I'll think more about it.

Rossen: I'd love to hear more though.

<jcraig> Ask jc

<Zakim> jcraig, you wanted to mention two concerns: this seems like inherently (or at least apparently) blocking API, and the attr name “virtual content”

James Craig: The issue with google docs, pages for iCloud, the structure is so complex and unrelated to a norm accessibility tree structure, aria live regions will be used a lot.

James Craig: Input Career, content editable region. Use aria live to make it accessible.

James Craig: Back to ... Shawn, is that a fair rep of google docs?

Shawn: Fair for one interaction. Braille is different. Definitely a common thing across browsers.

James Craig: 2 concerns. This is a problem we should solve. Load more is valid all over the place.

James Craig: Above, below sideways.

Rossen: More clarification. I want to learn the pattern, learn how a sighted user would interact with safari and mac and trigger all of these content fetches.

James Craig: Not in web?

Rossen: Yes on the web. You mentioned iCloud or app?

James Craig: iCloud and Google Docs implement accessibility work-arounds, not a pattern we want to keep.

Shawn plus ones

James Craig: 2 concerns are... seems like a blocking api. In normal content would that be native or plain symantic html, in voice over you roter over to...

James Craig: User lands quickly. In the scenario you describe. If it's 20 pages down you are talking about a block of seconds maybe minutes in some cases while the page scrolls.

James Craig: User may become confused, or will be announced that the application is busy. This feels like a... I think the value of a load more widget to purposely activate it is valuable.

James Craig: Putting other content like headings feels like the wrong solution to that problem. I can get behind load more, but using this to jump to next heading won't solve problem.

Rossen: How will sighted user have better experience?

James Craig: That user's experience is to scroll and then stop.

<joanie> +1 to some sort of load more widget

Rossen: Why are we trying to have a different experience for the AT users?

Shawn: If you scroll a doc quickly, you get visual indications of the shape of the text. If you see something big you will stop because it appears to be a heading. It's virtualized.
... This would have to be a 2 step process.

Rossen: Let's say we have a way to trigger the scroll. How will that differ? As AT sees no more headings, they will continue to hit the scroll even faster than sighted user.
... You will get ... the content that is blurred/pre-rendered into the actual content.

Shawn: It's rendered in canvas, starts blurry and then gets sharper.

<alastairc> If the web app has a virtual representation (blurry view of blocks of text), could it provide a semantic map of a similar nature?

Shawn: The rendered content would take forever if you incrementally scroll rather than the abstracted visual James described.

James Craig: My point is... I think you are leaning to scrolling... web developers don't have to do anything special.

James Craig: Key think here is what happens, say the implementation was done perfectly, what happens if user swipes down with rotar, user expects to happen immediately.

Rossen: You aren't talking about... app level logic that is capable of displaying table of contents, that already has links. There should be no difference because this is the case today for AT users.
... If I go and pull out table of contents and navigate to 5, and I'm on page one, and on google docs I'm assuming triggering link will work the same way.

Shawn: It would still apply.

James Craig; 2nd concern is naming virtual content.

Alice: We can discuss off line.

<Zakim> joanie, you wanted to suggest we *may* need/want some browser implementations to help us out with the AT "innovations" due to how accessible scrolling APIs work.

Joanie Diggs: I am in favor of a scroll to widget or something like that or some other solution for a different reason.

Joanie Diggs: I assume I want to scribe the document with the id, what I can do in my api I can scroll an object in relationship to ... scrollable thing.

<jcraig> S/Diggs/Diggs/

Joanie Diggs: I don't have a way to scroll the bottom of the article to the top edge.

Joanie Diggs: If there was some recognizable widget that is get me more stuff, I could scroll that to the top edge.

Rossen: Perfect example of what I described in the beginning. It doesn't have to be.... scrolling into view for that would serve both purposes.
... May not have explained it that well.

Charles L: I see parallels with ebooks. You are in chapter 1 and you can scroll to bottom and chapter 2 appears. There might be use cases for publishing.

Rossen: Absolutely. We discussed a little bit with internal team that works on epub viewer. Yes.
... I can see adding this type of trigger as they prepare epub content.
... two windows side by side. windows on left and chrome on right.
... If I go through headings, I know the doc has 8.
... As I try to go to next heading, there are no more headings.
... <presents demo>

<jcraig> (Narrator SR demo)

Rossen: Live code.

joanie: "Section loading content?"

Rossen: That came from a live region for the demo.

<aboxhall_> #xr-a11y

<aboxhall_> dangit

This is scribe.perl Revision of Date 
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_HTML_Format (score 0.99)

Succeeded: s/Joni/Joanie/
Succeeded: s/Joni/Joanie/g
Succeeded: s/Digs/Diggs/g
Present: Jemma_ aboxhall_ CharlesHall achraf melanierichards CharlesL Benetech Joanmarie_Diggs Roy mhakkinen MasakazuKitahara mounir Chuck
Found Scribe: chuck
Found Scribe: Lauriat
Inferring ScribeNick: Lauriat
Scribes: chuck, Lauriat

WARNING: No "Topic:" lines found.


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)