alexander :surkov (:asurkov) Reporter
	Description • 10 years ago

I think CSS flexbox order should be reflected in accessible tree so AT doesn't worry about it at all

	alexander :surkov (:asurkov) Reporter
	Comment 1 • 10 years ago

from impl point, we have nsFlexContainerFrame that keeps its sorted child frames in mFrames. I'd be good to hook into AllChildrenIterator::GetNextChild() and fix explicit children part so no special support on a11y side.

Trev, do you have ideas on it?

	Daniel Holbert [:dholbert]
	Comment 2 • 10 years ago

If I understand comment 0 correctly, it might actually be an explicit non-goal.

The flexbox spec says in section 5.4.1: "The order property does not affect ordering in non-visual media (such as speech) [...]  Authors must use order only for visual, not logical, reordering of content"
Link: http://dev.w3.org/csswg/css-flexbox/#order-accessibility

I'm unfamiliar with the "accessible tree", but based on this spec-text, I'd expect that "order" should *not* influence it (or be reflected in it).   Maybe I'm misunderstanding comment 0, though -- could you clarify what your intent is here?

(See also bug 812687 -- due to how we implement "order" [by reordering the frame tree, as you note in comment 1], we do currently allow "order" to influence the "tab" key's traversal-order -- but that's a bug.)

	alexander :surkov (:asurkov) Reporter
	Comment 3 • 10 years ago

I agree per spec the bug is rather invalid. I've got the request from the screen reader vendor, I think they have use case but, again, per spec their usecase is rather 'non-conforming' like, for example, if people start to use 'order' for sorting columns in grid control.

it's out of the bug but example 6 looks suspicious with me since tab navigation will be 2nd tab, 3d tab and then 1st tab (selected) - that's rather a confusing UI and looks like also 'non-conforming' example

Concerning example 7 where article goes first in DOM but visually after navigation block makes sense because the user navigates right into the content skipping the navigation block.

	alexander :surkov (:asurkov) Reporter
	Comment 4 • 10 years ago

I've been told that there's a proposal to make a11y and tabindex follow flexbox ordering what makes bug 812687 invalid but I hadn't been given a reference. Do you have one?

	Daniel Holbert [:dholbert]
	Comment 5 • 10 years ago

Yes -- this was hinted at in http://lists.w3.org/Archives/Public/www-style/2014Nov/0326.html , but so far I'm the only one to respond in that thread.

(I just chimed in with some context/links explaining why things are the way they are. It seems like the folks working on the proposal weren't aware of that background info until now, per http://lists.w3.org/Archives/Public/www-style/2014Nov/0355.html , and I'm not clear on whether the proposal is still coming or not.)

	Daniel Holbert [:dholbert]
	Comment 6 • 10 years ago

(I don't know whether the flexbox spec-editors were involved in the TPAC discussion referenced in that thread, or whether they've expressed any opinions on it. I suspect they were not involved/aware [though presumably they're aware now, after the www-style thread], & I suspect that they'd not be likely to accept such a proposal at this late stage of the game.  But they haven't commented publicly yet, so I don't really know.)

	Adrian Roselli
	Comment 7 • 9 years ago

A reminder that this is still out there. I made a test page to show what happens when a user tabs through the focusable areas depending on the browser: http://codepen.io/aardrian/full/MavVeb/

All browsers except Firefox follow the source order. Flex Editor’s Draft (14 September 2015) also suggests that Firefox's behavior is non-conforming:

"Likewise, order does not affect the default traversal order of sequential navigation modes (such as cycling through links, see e.g. tabindex [HTML5])."

https://drafts.csswg.org/css-flexbox/#order-accessibility

Animation showing the tabbing in Firefox: https://twitter.com/aardrian/status/653954728506826752/photo/1

Animation showing the tabbing in Chrome: https://twitter.com/aardrian/status/653954368283217920/photo/1

	Marco Zehe (:MarcoZ)
	Comment 8 • 9 years ago

Hm, from comments 1 through 6, it sounds like this bug here is actually invalid, and bug 812687 should be fixed instead. Alex, did I capture that correctly?

	Daniel Holbert [:dholbert]
	Comment 9 • 9 years ago

(I think that's correct, yes.)

	alexander :surkov (:asurkov) Reporter
	Comment 10 • 9 years ago

(In reply to Marco Zehe (:MarcoZ) from comment #8)
> Hm, from comments 1 through 6, it sounds like this bug here is actually
> invalid, and bug 812687 should be fixed instead. Alex, did I capture that
> correctly?

as long as the spec says that flexbox is about visual order not logical one then we shouldn't do anything here.

	Jen Simmons [:jensimmons]
	Comment 11 • 9 years ago

There's a good blog post about this at: http://adrianroselli.com/2015/10/html-source-order-vs-css-display-order.html

I don't know which implementation is correct, but the lack of interoperability between browsers is a problem. Every browser needs to do this the same way, and right now Firefox is the outlier.

	Daniel Holbert [:dholbert]
	Comment 12 • 9 years ago

@jensimmons: I think your comment 11 is really for bug 812687.  (Yes, we're wrong on tab-index/accessibility-index with 'order' in flexbox, according to the spec, though per bug 812687 comment 7, there was a serious proposal for a long time that the spec change to match what we do.  The existence of that proposal made it significantly less worthwhile to spend time implementing what the spec says.  My impression is that the proposal has fizzled, though, so we probably shouldn't take that into consideration anymore.  I agree we should fix it; I don't have cycles to take it now, but it's on my list of flexbox bugs that I'd like to fix, when time frees up.)

	Jen Simmons [:jensimmons]
	Comment 13 • 9 years ago

Thanks Daniel, @dholbert: Sorry to be on the wrong ticket. I'm still finding my way around Bugzilla.

	Daniel Holbert [:dholbert]
	Comment 14 • 9 years ago

No worries! Thanks for commenting over there. I'll drop the "DevAdvocacy" tag from this bug here.