v2.x - a step backwards in accessibility

[DavidJessurun]

Hi all,

Adoption of CMSMS for us, was in large part driven by the promise that the team was working on accessibility. But now that I had my first look at v2.x, I wonder if anyone in the core team read the WCAG prior to building/OK-ing features?

For example: some inputs are drag & drop. Please sit down, disconnect your mouse, and tell me how to use this? Come on folks, this is like the most basic of basics here... This affects people with motor issues, the non-sighted ...

Please note that our core business is building websites that pass inspection. Please note that with the UN treaty in place most western countries have committed to accessible government services and this includes back-office.

We regularly hear about people losing their jobs because due to disability they cannot use the software/CMS anymore.

Get it right, please...

[DIGI3]

Thank you so much for your offer of assistance to this open source project. The contribution of a fully-accessible admin theme would be a great help to our already stretched Dev Team resources.

Feel free to contact me if you need any help with testing, and/or for making it available to the public.

Again, we really appreciate your generous time contribution.

[DavidJessurun]

While I appreciate your 'If it's not to your liking, fix it' standpoint, given that this is an open source project - and I would be glad to offer any assistance that I can, I must stress that accessibility is not charity. It is the baseline measure of quality.

My time is extremely limited. But I will be happy to feed back into the project any improvements I devise.

Things like drag & drop menu's are really not something I can 'fix' quickly. I am not a good coder. I do not love coding. I do it out of necessity; slowly and often badly.

It is also serious enough that I would suggest giving it top priority.

It should be fully accessible standard, with inaccessible 'snazzy' menu's as option. Not the other way around. The days we sent people to the back door are behind us, I should hope.

Let's face it; accessibility in this case isn't mandating that you put in extra work. It is the other way around. You put in extra work for a slick option that added little benefit other than appearance. And it backfired.

It's like this with many accessibility requirements; it's not that dev's and designers need to fix things, we need to stop breaking them. From the get-go.

Another example; the video manuals on the website. Very smooth. Looks impressive and certainly could be of added benefit. BUT; to a very large portion of users they are actually a hindrance. The deaf, the non-sighted, the dev at work trying to quickly find something so they can get on with work...

If you think about it; making video's is loads of work, and I'm not saying you shouldn't do it. But a simple typed manual would be just fine for 80% and 20% can't use the videos in any case.

And to make a video, you are typing the score to read... so it's not as if you aren't typing in the first place...

See where I'm going with this?

I think you may find that flipping the perspective, and treating accessibility as baseline, not as extra, will actually lighten the burden on the dev team. Sure, you can't do some things... but that also means you don't have to do them.

And 20+ years experience, among others in interface usability testing and marketing/branding research taught me that people go 'wow' at 'features' ... but stay for utility, and interfaces users describe as 'smooth' and 'slick' and 'painless to use' generally are a lot more spartan than many designers think. Sadly, most people only register the initial 'wow', not the subsequent low-grade continuous frustration when the 'wow' actually gets in the way of them using the product.

Just sayin'...

Anyway, bit of tough love here, but it's love.

Thank you for your attention/time.

[DIGI3]

Thank you. This was a much better approach than your first message, and something we can work with.

What a lot of people don't realize about projects like CMS Made Simple is just how small of a group of contributors there are. The current Admin Theme was contributed by basically one person (who is no longer involved).

Accessibility actually has been a topic in the Dev Team lately, as well as a mobile-friendly admin theme. At this point, because the themes didn't really start with these as a priority, it's an incredible amount of work for volunteers. Personally I have about 2-3 hours a week I can devote to CMS Made Simple, and most of that is spent scrambling to keep the documentation at least somewhat up to date. Even that 2-3 hours is time I'm not spending with my family, time I'm not billing to clients.

That said, I will discuss this further with the Dev Team and hopefully we can improve on this area. If nothing else, perhaps we can put a call out for volunteers specifically addressing this area.

[paulbaker]

For example: some inputs are drag & drop. Please sit down, disconnect your mouse, and tell me how to use this?

Well I didn't actually disconnect my mouse, but I didn't touch it. I navigated to the File Manager (is that what you're referring to?) on a V2.0.1.1 site. And I managed to upload a file. It took a hideous amount of tabbing and it often wasn't clear to me what link had focus on the screen. I suspect if you have to use keyboard only inputs you would be able to do it much quicker than I could (because you would have a lot more general experience) and you might even have browser plug ins to help.

So I don't think V2 is a "step backwards" because you can still upload without using the drag and drop. But I take your general points.

[DavidJessurun]

Drag & drop never works without a mouse. Look at the Design Manager interface.

Non-sighted users use speech software and a braille bar. Others tab & arrow. And yes; they get real fast with it.

Now, I'll admit there won't be many non-sighted designers, but I know a fair few non-sighted coders.

My take on it is that everything should comply to WCAG 2.0 out of the box, from backend interface to example code (because, not polluting the industry with more bad code. Too many tutorials and howto's out there on how to break stuff that works already) to ... you name it.

For one, it's not at all that limiting in what you can do design-wise and if it is... this is a CMS, a tool. Tools are beautiful because design and function work together, not because of bells & whistles.

Just my take on it.

Like I said, I'll gladly feed back what I fix, but I rerely do hands-on work anymore. I'll also gladly answer questions.

I understand an open source project depends on volunteers and if one steps up, I'll gladly do some hand-holding.

Until then, all I can do is post here.

[Sponsi]

I agree with the autor of this post.
CMS MS 2.0, in terms of programming, might be a step forward, but the ease of use, the workflow, the AI is sooo dense, so "thought of by a programmer".