Fix keyboard tab order of menu options in manger uberbar (accessibility defect)

[paulbohman]

For compliance with Web Content Accessibility Guidelines (WCAG)

The order of objects in the DOM differs from the visual order. The way the links are laid out visually, I would expect the order to be:

MODx/home logo
search
content/media/extras/manage
user menu
gear/system menu
help icon

The actual order starts with user and goes to the right and then goes back to the MODx home and across the left menu, which is not intuitive.

See accessibility to-do list at https://dequeuniversity.com/modx-accessibility.html#uberbar

[Mark-H]

Just had a quick look at that link...

While I think it's a great analysis and we definitely need to address
those, please tell me you're not in the process of adding dozens of new
issues for every item in that list... We've got a lot of issues already and
adding a ton more won't help in getting them resolved.

Could you summarize the required accessibility fixes per section (e.g. all
aspects related to login in one issue) instead? That would make it a lot
more convenient for developers to address these issues. Of course if you
know your way around code, pull requests would be very welcome.
Op 15 nov. 2014 23:40 schreef "paulbohman" notifications@github.com:

• Tab order:
  • The order of objects in the DOM differs from the visual order. The way the links are laid out visually, I would expect the order to be:
    • MODx/home logo
    • search
    • content/media/extras/manage
    • user menu
    • gear/system menu
    • help icon
  • The actual order starts with user and goes to the right and then goes back to the MODx home and across the left menu, which is not intuitive.

—
Reply to this email directly or view it on GitHub
#12150.

[paulbohman]

Well, tell me how it would be most useful for you to have these issues addressed in the bug tracking system. I was going to add an issue for each one, yes, because that ensures a one-to-one correlation between issue and fix, but I'm open to doing it however you feel is best. I was hoping that we could add an "accessibility" label to the bug tracker so the issues could be compartmentalized within the bug tracking system, which should make it less overwhelming if the issues can be filtered that way.

[paulbohman]

Oh, I see what you were saying. Yes, if you want me to put all accessibility concerns for a given component in one issue, I can do that. Some of the issues are complex enough that they probably ought to be their own entry, but I'll try to consolidate them.

[Mark-H]

Yeah, we already have so much issues open it's unwieldy as is, and
consolidating as much as possible would at least help not make it worse ;)
that's my opinion anyway.
Op 15 nov. 2014 23:52 schreef "paulbohman" notifications@github.com:

Oh, I see what you were saying. Yes, if you want me to put all
accessibility concerns for a given component in one issue, I can do that.
Some of the issues are complex enough that they probably ought to be their
own entry, but I'll try to consolidate them.

—
Reply to this email directly or view it on GitHub
#12150 (comment)
.

[dubrod]

moved to a11y project - modxcms/a11y#21

[rthrash]

This is being addressed at the MODX Accessible CMS Project, and with Paul's agreement has been moved there. For more details, see #12156 (comment). Thank you!