Dashboard page navigation does not gracefully degrade with CSS off

[jidanni]

Try the dashboard with a text browser (lynx, w3m) or with stylesheets
turned off, you will see that for dashboard page the navigation menu
must be scrolled over to get at the meat of each of the various dashboard pages clicked.

Contrast with MediaWiki pages, where the navigation is placed at bottom.

[Denis-de-Bernardy]

Suggesting wontfix unless a patch comes up. Else, this ticket will rot for ages.

[johnbillion]

This is a super easy thing to fix (a 3 line patch), but the problem it introduces is we have to move the 'adminmenu' hook too. This means the hook moves all the way from the beginning of the page down to the end, and will probably break plugins.

Patch attached.

Opinions on whether this is workable or not would be appreciated.

[nacin]

I'm not sure we can do this without breaking a lot. I know there has been some thought of a very accessible version of the WP admin being created, for screen readers etc. We're no-JS supportive, but not at all no-CSS supportive.

Marking for ux-feedback, let's see if Jane has any thoughts here. I imagine it'll be a wontfix.

[johnbillion]

Related: #9698

[jane]

I actually would like the admin to look nice and be easy to use without CSS on, but it's too late for 3.0 a)in general, way past freeze, and b) because as Nacin says, it might break things. We should look at it in the next version. Not a top priority, but something that would be good to do if the patch tests out okay.

[johnbillion]

Westi grepped the plugin repo this morning and found that not one single plugin uses the 'adminmenu' hook. This means there is no issue with regard to this hook moving.

What else could potentially break in plugins if this patch was applied? JS? CSS?

[nacin]

I didn't even know there was an adminmenu hook.

A lot could break here for sure, so let's evaluate in 3.2 and see what we could do about it.

[johnbillion]

I wonder if there's still time to evaluate this in time for 3.2 as per ​http://make.wordpress.org/accessibility/?p=12.

We could introduce the change in trunk as a test run to see if any problems arise. As we've seen, the adminmenu hook is used by zero plugins, leaving custom JavaScript as the only real place this could cause breakage.

[saracannon]

Replying to johnbillion:

Westi grepped the plugin repo this morning and found that not one single plugin uses the 'adminmenu' hook. This means there is no issue with regard to this hook moving.

What else could potentially break in plugins if this patch was applied? JS? CSS?

Just because plugins in the repo aren't using the hook doesn't mean that people aren't utilizing it internally for their own custom CMS's. We should be careful.

[grahamarmfield]

Would not an in-page or 'Skip' link at the top as I suggested in #21310 not help with this one?

[sabreuse]

Skip links were added in [21435]. Closing as fixed based on that. If there are any new issues, let's move those to new tickets about the specific issues since the whole structure of the admin has changed since this ticket was originally raised.