<janina> Thanks, Shane. BTW, got your Spec-Ops email and will respond.

<fesch> scribe:

<fesch> scribe: fesch

preview agenda with items from two minutes

<ShaneM> rese/me is lurking

js: anyone with news or items?

lw: web platform WG looking at picking up bugs and cary on activity, anyone in APA interested in joining?

jf: I like that

lw: we are predominately European so the time may reflect that

cs: had a post about edge and one pillar is accessibility

<ShaneM> Note that W3C is switching over to new stylesheets on 1 March

jf: activity in TV around a cloud based browser, JF working with them about accessibility requirements

fantasi: bug in Chome about following links fixed

<Gottfried> New parts of ISO/IEC 24752 Universal Remote Console, approved: Part 7 on RESTful target integration; part 8 on user interface resource framework.

jf: W3C switching over to a new style sheet, thanks for be sensitive to accessibility concerns in the new style sheet

CSS Flexbox & A11y

<Gottfried> (Regarding my above message: The projects for part 7 and 8 were approved; the documents have yet to be developed and approved.

js: where to start?

mk: consider starting with whether we have a proposal? Not sure where to start?

js: don't think we have a proposal, concerned that flexbox preserve reading order, benefits of reorganizing onscreen display can live with reading order

mk: there is an engineering problem - we want reading order and keyboard sequence to preserve accessiblity
... differences in approach, where some people think that the reading order can't always be controlled by the DOM others think reordering the DOM is feasable

mk; everyone sees an appeal on not having to rely on the DOM, but once you dig into the weeds, then having a single way of controlling the reading order is nice - predictable

fantasai: keeping the DOM order is easy to work with authors

<Rich> https://lists.w3.org/Archives/Public/public-apa/2016Jan/0025.html

rs: I put the post out on a solution see link

<JF> +1 to Rich's point - "disable CSS" is not a good "accessibility test" today

rs: we have lots of stuff like content injection where you can't see it in the DOM, flexbox affects user interaction

<LJWatson> +1 to Rich's point about disabling CSS no longer being enough.

rs: if you change the way stuff appears so it doesn't follow the DOM order... you can't say that you do this and don't change the keyboard and reading order
... we put Bo Campbell in CSS to try to express this concern and feel he was ignored
... we are so far beyond using the DOM, that CSS needs to address the read order and keyboard issues

rosen: we have CSS WG culture and flexbox, we didn't ignore Bo Campbell, we listened and spent significant time spent
... if you don't think we have spent enough time, please bring it to my attention

<fantasai> Fwiw, I have personally spent hours chatting with Bo about these issues outside of meetings. Definitely not ignoring the issues.

rosen: CSS interacting and changing presentation - before: and after: defined to be accessible, if not implemented they are bugs
... to say CSS is creating inaccessible content by design is not true, we design it to be accessible
... what is the right thing for the AT to follow? the DOM or visual order?
... flexbox does not affect tabindex, then you have to ignore the order
... if you are in the AT business and if you want to follow the order property, you can follow the visual order
... so you can follow the DOM order until you run into a subtree ordered by the order property

fantasi: there is a bug, not an intentional thing

rosen: if you want to experiment different ways to tab, they could experiment with the property order

<fantasai> IMHO it would be wrong for an AT to follow 'order' but not also figure out spatial relationships expressed in other ways (abspos, floats, etc)

cs: difference between the UX and web platforms - accessibility part of flexbox, the browser or AT or browser could change to use the order property - one of the things we trip over with CSS we have typically thought about 2 modes with mouse and with AT
... but a user can use any combination of keyboard, visual, speech...
... then the models break down, instagram uses the flexbox model and if you try tab on instagram in Chrome... it is very odd since you have to go through every thing then get to the header last...

<JF> +1 to Cyns comment "it's really confusing" and hoping that the CSS WG is also thinking in terms of cognition issues like that

<LJWatson> +1 to Cyns.

cs: user agents should be free to design an experience that works best for their user

<Rich> https://www.w3.org/TR/html-aam-1.0/

<Rich> https://www.w3.org/TR/svg-aam-1.0/

rs: one core problem with CSS, AT when they interact the browser, goes through the APIs

<Rich> https://www.w3.org/TR/core-aam-1.1/

rs: they all say how the marked content maps to the APIs, but the AT's don't go through the DOM for the order, they rely on the user agents to map...

<Rossen> ?

rs: if you go in some browsers, if you inject content, it never makes it in the API... CSS is the only core group that doesn't pay attention for this
... if you look at web components, you have a separate DOM to look at it, so you need a mapping spec and you don't have one
... I like flexbox, but you don't have a mapping spec

mk: want to emphasis that Cynthia said - that we have predictable order, people forget a blind person knows where things are in the screen, you can touch your screen, but if it doesn't match what I hear in the screen reader, it is very frustrating in the least
... so the visual ordering needs to align with the reading order and visual keyboard order - I hope no one is arguing with that
... I hope we are in agreement the physical appearance in the screen is important to all users
... I hope we can focus on a solution
... injected content is a separate issue

<fantasai> As Rossen said, generated content is supposed to be exposed in the AT

<fantasai> That's an impl bug, not a spec bug

mk: where are the engineering arguments for not relying on the DOM order?

lw: as far as I know injected content is in browsers other than IE

mk: did you test it with something not related to naming
... if you check with real content, it isn't

lw: if we look at the potential disconnect between the visual order and keyboard, and read order we don't have any ARIA tools to fix the problem. Developers don't get it...
... may need to look to the browser to fix this

mk: when you are talking about flexbox in combination with DOM order, no different from others in DOM reordering
... why is unreasonable to do for authors

lw: expensive to do

mk: I don't think that is substantiated, I've asked lots of engineers, shouldn't we get them validated

fantasai: there is a linear way to provide navigation, AT should be able to do it, the user agent should know right from left... and AT should provide a way to do it

rs: first of all the AT needs to know when to do it. we have a issue that CSS does not say how things get mapped in the API. Firefox put it in the visual order
... the next thing is the keyboard navigation - if changing the visual order, then change the keyboard navigation as well, I provided an algorithm to do it
... a bigger issue is we don't have mapping for these things

rosen: AT's don't realize ordering from web platform only, then they do their own enriched experience
... we should be allowing ATs to innovate on top of what we do

<Rossen> https://drafts.csswg.org/css-speech/#content

Rossen: can find via DOM properties and AT APIs

rosen: generated content should be in the accessibility tree
... Rich pointed out each major module making their own explainers, a good idea, not in the speech module

<cyns> add note: User agents, including browsers, AT, and extensions, may choose to add spacial navigation features based on the order attribute or other mechanisms that expose visual layout.

cs: I want to make a concrete proposal for a note

<Rossen> https://drafts.csswg.org/css-flexbox/#propdef-order

<Zakim> cyns, you wanted to suggest changes to this part of the flexbox spec https://drafts.csswg.org/css-flexbox/#order-accessibility to clarify UA control over user experience

fantasai: I am happy to add the note if we replace the or - with an and

<LJWatson> @MCK the W3C JavaScript best practices wiki states "To make sure your code is fast and doesn't slow down the browser, try to keep DOM access to a minimum..." https://www.w3.org/wiki/JavaScript_best_practices#Keep_DOM_access_to_a_minimum

fantasai: you should be making your best effort to handle the order property and absolute the positioning, to do order property and leave everything else as is doesn't make sense

<MichielBijl> @fantasai: good point. I know image maps do that (sort of).

mk: I am under the impression that at least for screen readers, screen magnification our objective was to provide a determinate solution, provided by the user agent and not have to not can't
... I am not aware of any screen reader to read properties, the only use was to hack, fix problems, no AT vender wants to do that

<Zakim> cyns, you wanted to say I meant an inclusive or. and is fine

cs: and is fine

rosen: I agree with Matt, yet we want to be able to encourage AT vendors in everything, to expose in AT layer automation... and value everything they value in JAWS
... they go to great lengths to achive the experience they have

mk: In my work with Glen and the developers at Freedom Scientific, they express do this is a hack and they want to get away from it. It is always to close gaps they couldn't close any other way

rs: agree with Matt. If they want to expand to the product to add services or whatever that is fine. But when you have to put into hacks.
... But if NVDA does it a different way, then it frustrates developers, so we need the CSS working group do the same kind of thing for testing and predictability
... we are trying to get edge more accessible by using APIs

js: what are our next steps?

rs: wants CSS to do what other WG are doing

<fantasai> I'm happy to take an action item to add Cynthia's note to the spec today, fwiw!

rossen: want closure on the flexbox thing, the conversation is fantastic, but on flexbox - Cynthia's proposal

rs: no that is not enough to address the issue
... and it doesn't address the keyboard order
... here is what happened at IBM, a product team used flexbox, so what they had to do was restructure their whole DOM. And they folks with disabilities get beat up because we haven't addressed it in the spec

<Zakim> cyns, you wanted to say that the intent of my proposal was to address keyboard order

cs: I think my proposal does

rs: I don't think it does... does that include keyboard order?

cs: yes

rs: need the API discussion

cs: I don't think we should block them

rs: I disagree

mk: I didn't see anything in the note which specifies what a user agent will do, and I don't see anything that makes it clear what will be done - that is a big problem

js: sounds like we need a CSS mapping guide
... to flow content appropriately, the accessibility aspect needs to be interoperable,... ran out of time, we aren't done
... anyone need to comment before the call closes?

cs: I don't agree with Matt

js: COGA is telling that to

mk: looking for user agent behavior needs to be predictable

js: since we meet at the same time, maybe we should take advantage of that

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/rosne/Rossen/
Found Scribe: 
Found Scribe: fesch
Inferring ScribeNick: fesch
Scribes: , fesch
Present: Rossen cyns fesch JF Janina MichaelC matt_king fantasai Joanmarie_Diggs Rich_Schwerdtfeger LJWatson MichielBijl JamesN

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

Found Date: 24 Feb 2016
Guessing minutes URL: http://www.w3.org/2016/02/24-apa-minutes.html
People with action items: 

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