Describe the bug
The tab order when changing a post's publish date is confusingly wrong.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Selection happens in the order of the visual appearance: first the day should be selected, then the month and year and so on.
Screenshots

Desktop:
Chrome 70 on macOS
Additional context
Gutenberg 4.1.1 on WordPress 4.9.8
What do I need to do to get the date format in that order? I've tried a few language/date format settings but I can't get it to look the same. I'm wondering if the rules for the date time display don't take certain settings into account.
@LukePettway j. F Y & H:i
@Soean I see now, thanks for the help. It looks like flexbox is being used here to change the order of the boxes visually but the tab index doesn't change when that happens.
I wonder if there is a better way to order these using React instead of relying on CSS to do it.
I wonder if there is a better way to order these using React instead of relying on CSS to do it.
Yep, the CSS property order should never be used to change the visual order, when the order affects meaning or operability. (WCAG guideline)
Also reported on core Trac: https://core.trac.wordpress.org/ticket/46337
I tested this a whole bunch and, try as I might, I couldn't seem to replicate this one with any different date format settings鈥攖he tab order matches the visual order.
Would anyone be willing to have a quick check to see if this might have been accidentally fixed at some point?
If I'm not wrong this was fixed in https://github.com/WordPress/gutenberg/pull/11863 @LukePettway can you please confirm, when you have a chance? 馃檪
Note: I see the date-time component stylesheet has still one order: 1; property: it doesn't have any effect now and should be removed. Basically all the three Day, Month, and Year containers have order: 1;
@afercia I thought I fixed this too!
Cool, thanks. Seems to me the only thing left to do is removing this CSS property:
As far as I can tell it's a leftover and doesn't do anything.
The PR didn't have a Fixes #11566 text in it, that's why this issue wasn't auto-closed.
Lovely, thanks @afercia @LukePettway @swissspidy for double-checking this! I'm nixing the extra CSS (it actually looks as though we can remove all three lines) and then closing this out once that PR is merged.