Description: This component relates to bugs in our support for accessibility APIs on the various platforms. Accessibility APIs allow 3rd party products, such as screen readers used by visually impaired users, to communicate with our content and UI. The APIs we support specifically are MSAA on Windows and
ATK on UNIX/Linux (Apple has not yet published specs for an accessibility API on OS X). This component is not for keyboard, focus or any accessibility bugs other than those relating to the APIs we export.

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?

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.)

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.

(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.)

(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.

@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.)