Segregate Accessibility to a separate theme?

jpdevries commented 8 years ago

Summary

When the below issues are closed are they addressed or simply moved to the a11y project?

As issues like these arise that could be addressed in the default theme as well, should they be? The concept of accessibility only having a place in an a11y theme and not the default theme is a concept of segregation and goes against what accessibility is all about. It implies that there are "those users" that need accessibility, and they will switch themes, and then there is the rest of us.

Accessibility is water. We all need it.

We all lack abilities, and are thus disabled, given on the context of the devices we access experiences through. The last time you used a touch device you may have had the same physical and personal abilities but could right click?

iOS doesn't have a separate binary for "those users". You go into settings and find the same accessibility settings as everyone else. This is because the eagle-eyed user on a road trip may have just as much use for the ability to use a screen reader to read articles aloud as the blind. The EU doesn't use specific Euro bills for blind users. Everybody uses the same bills and the a11y considerations made for the blind help sighted users as well when they are sorting or feeling for a specific bill. That is accessibility done right.

Person != User

If I'm working on a MODX site from a desktop using the default theme and then I go to lunch and bring my mobile device I'm still the same person but now I am a different user who relies more heavily on accessibility considerations. Should I switch my manager_theme setting every time I switch devices?

MODX users deserve a system that understands accessibility is something developers should start with and not only deliver solely to a select group of opt-in users.

Observed behavior

Users must install a separate theme for a11y considerations.

Expected behavior

Users should not have to install a separate theme for a11y considerations.

Environment

MODX 2.x.

Mark-H commented 8 years ago

It is indeed the goal of the a11y project to feed back changes into the core. The specific issues that are on the list to be ported are now tagged as "port to revo/core": https://github.com/modxcms/a11y/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3A%22port+to+revo%2Fcore%22+

It sounds like the reason it's in a separate theme currently was to allow moving quicker, allowing more experimentation to get it right separate from the standard process that might be a bit more... risk averse ;)

jpdevries commented 8 years ago

In the a11ySlackers channel I asked people's take on whether or not a UI drawn from JSON (HTML-last) can be truly accessible https://gitter.im/w3c/a11ySlackers?at=569e42b6a03e28ad1adf9539

Got some interesting opinions from

"All that matters is the user experience. ;)"
Nope. As long as the generated output is all semantically sane, it doesn't matter when it gets inserted in the DOM.
People with disabilities are not more likely to not be running JS than people without disabilities

to

Guess it depends what you mean by accessible. If JS has to build a bunch of HTML elements after the fact, then anyone in a train's prolly not going to access that very well...
So, accessible to people with no network problems, no conflicting scripts, no ISPs injecting crazy stuff too, etc etc. Well they get nothing, if you start with nothing. They get
you could start with something that works (which would be HMTL) and yeah, you can layer on anything thats "extra" as much as you want
by having inaccessible internal app, they'd be basically ensuring they never will have disabled people working for them. So having the stuff work for everyone internally is excellent.

to

I would be the biggest dickwad in the world if I only cared about people with physical disabilities but left out people who also can't help their situations like poverty and shitty bandwidths, and I certainly would never call whatever I built like that "accessible", even if it technically was to solely people with specific physical disabilities. That said, those of us who call "access" "access", it does still mean often specific, maybe extra attention needs to be made for people with physical disabilities because of the impact of code on them can be harsher-- otherwise you get an #allLivesMatter kind of thing, which is also BS (in terms of code)

I really like the point about how accessibility can be about payload as well, which is why I think it is an added bonus that with #12611 2.5 should have a lighter payload across manager pages while plugins are managed.

modxcms / revolution