New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segregate Accessibility to a separate theme? #12782

Open
jpdevries opened this Issue Nov 26, 2015 · 2 comments

Comments

Projects
None yet
3 participants
@jpdevries
Contributor

jpdevries commented Nov 26, 2015

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.

Related Issue

#12156
#12155
#12154
#12153
#12151
#12150
#12149
#12148
#12147
#12146
#12145
#12144
#12143
#12142

jpdevries added a commit to jpdevries/revolution that referenced this issue Dec 1, 2015

Improve keyboard / screen reader a11y of login screen
Tab order is now:
username
password
forgot your login
remember me
login
MODX link
language select

Closes modxcms#12145 (for reals)
Closes modxcms#12146 (for reals)
Closes modxcms#12147 (for reals)

Also see modxcms#12782
Also see modxcms#12791

Adds both aria-required="true" required and required attributes
although i think only required may be needed

jpdevries added a commit to jpdevries/revolution that referenced this issue Dec 1, 2015

Improve keyboard / screen reader a11y of login screen
Tab order is now:
username
password
forgot your login
remember me
login
MODX link
language select

Closes modxcms#12145 (for reals)
Closes modxcms#12146 (for reals)
Closes modxcms#12147 (for reals)

Also see modxcms#12782
Also see modxcms#12791

Adds both aria-required="true" required and required attributes
although i think only required may be needed
@Mark-H

This comment has been minimized.

Collaborator

Mark-H commented Dec 5, 2015

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

This comment has been minimized.

Contributor

jpdevries commented Jan 19, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment