State of accessibility

Community Newcomer's Corner
1

I’m searching for a new CMS right now and one of my major concerns is accessibility.

During the last days I spent many hours reading the docs, but I couldn’t find much information about it. Most other aspects from my wish list for a CMS seem to be solved problems - especially with Neos 9.

In the feature list on the website I read:

While accessibilty depends on the individual implementation and the editors’ care, Neos doesn’t obstruct you in building accessible websites. It even has options and tools to assist proper accessibilty and leaves any freedom necessary to build highly accessible websites.

This sounds nice, but is a bit unspecific. Also the post about accessibility guidelines didn’t get much feedback:

It feels like there is awareness already, but I would like to know about the priorization in the core team before I make a decision.

1 Like
2

Hi and welcome to the Neos community and thx for your interest and questions,

do you mean the accessibility of the Neos Backend or anything regarding whether Neos keeps you from building an accessible website?

And if you mean the backend, do you have something specific in mind, like contrast, screen reader support, etc.?

I think none of us in the team are super proficient with this topic, though we would love to do a better job at it with some additional help and sponsorships.
There were community members in the past who created issues, did improvements and gave pointers what can be done better, but it’s a broad topic and depending on the type of accessibility would probably require complete overhauls of existing components.
Lately this topic went a bit sleepy afaik.

Best
Sebastian

1 Like
3

I mean the accessibility of the Neos Backend.

In a perfect world, all aspects, but at first I think about keyboard navigation (tab, space, enter) to access buttons. When I edit the <h1> on the demo page, I can switch with Tab or Shift+Tab between nodes, but I didn’t find a way to access any interactive element without using a mouse besides CTRL+b for strong or CTRL+i for em.

Than I would improve the UI on small viewports. I noticed, that editing on my phone is a bit annoying. Solving this enables people with low vision, because they can zoom in.

I’m not a disabled person, but I started to care much more about these things. Also accessibility features are helping in other areas, like being able to work while being temporary disabled (accicent, RSI) or just because typing is faster than clicking.

I have strong biases about react (developers) or actually about JS frameworks in general because of nested <div>s with event listeners instead of basic form elements or <a> tags. Maybe it’s just a coincidence, but not knowing about basic, semantic HTML happens especially often in react land. Also because react SPAs try to reinvent native browser features (back/forward button). And because of the accessibility problems with WordPress/Gutenberg, which is actually more a business model or priorities problem, than a react problem.

While reading the docs I stumbled upon a few buttons, which should be links. I can’t remember, where I found them. I sat in the garden and was reading on my smart phone. But I remember, that I couldn’t long press the button/link to open a page in a new tab.

I also remember a code example in the docs about rendering a link as <a> or <button> based on a condition, which would produce invalid or non-semantic HTML.

found it: https://docs.neos.io/api/afx/syntax#complex-example

     <Neos.Fusion:Tag
       tagName={Type.isString(props.link) ? 'a' : 'button'}
      {...props.linkProps}
       attributes.href={props.link}>
         Read more
     </Neos.Fusion:Tag>

Now I had another look at the demo site and I found more <div role="button"> elements in the left side bar, which aren’t accessible with the space key. Using <button type="button"> instead would solve it immediately.

I didn’t have a look at the source code, yet. So I’m not sure, how much rewrite is necessary…

I search for a CMS, where accessibility has a high priority (or where only a minor rewrite is needed). Because Typo3 popped up a few times during my research I had high hopes in Neos. I guess, I’ll dig a bit deeper into Drupal now.

In case you are interested, I wrote two long forum posts, why I’m leaving my old CMS. Accessibility was one reason.

2 Likes
4

Thanks for your input, all valid points!

IMO the small screen support is not something that would happen soon. It requires better concepts, layouts and quite some work, for which we probably don’t get any budget from anyone in the near future.
Though sometimes improvements are made for tablet support >= 1024px.

Documentation examples can and should be fixed. We are always happy for input there as the documentation is being written by various people from the team and the community and is a collaborative effort. The AFX frontend rendering example you found is simply not very good IMO and should be improved.

Regarding the React backend, there are various topics we deal with. One is non-semantic code, this can and is fixed when stumbling upon it, though we have no one looking for it. Actually in the last few Neos code sprints quite a few of those issues were fixed by community members.
We have plugins we rely upon that have their own issues, that we cannot always easily create workarounds for. So this is something that sometimes takes years to be replaced or fixed.

F.e. I often work on performance topics for my customers, to make the UI quicker to use or add new extensibility points, so they can create better plugins for their own use. But nobody ever came to me and asked for better keyboard support. Though that’s something I struggle myself with, when writing my blog posts in Neos or with some of my own plugins.

So what I want to say:

We are very happy if someone opens issues (PRs are even better) in our Github repos regarding those topics and helps making Neos better. We are mostly 3 devs working on UI topics and most of the funding we get is for new features or bug fixes. So we require the help from the community to find and resolve all those inconsistencies and usage issues.

So even if you move on to another system, it would be highly appreciated if you have a list of issues you found and would create one or more Github issues out of that, or even only write them here and I copy them to Github.
And if you stay it would be great, as we could benefit from a regular feedback round and someone who can test and verify improvements.

3 Likes
5

@sebobo Thank you very much for your feedback. It helped a lot to make a decision - in this case against Neos. I’ll probably study the whole node/dimension concept a bit more at some time…

Instead I decided to learn Drupal, especially because they promoted accessibility issues from “feature” to “bug” a few years ago. Also because I wanted to avoid react - for Drupal addons I can write vanilla JS. And because a speaker in a Neos Con 2019 session said, that Drupal is also useful for small/medium sized websites.

Some last thoughts…

I don’t have much time right now (because I have to learn a new CMS), so I won’t open Github issues or PRs.

The modals (e. g. to add new node) on the demo page aren’t responsive. My Firefox dev tools at the bottom of the page overlapped e. g. the cancel button. There 's probably a min-height somewhere, that should be a bit smaller.

Fixing the small viewport issue might help your speaker with 10% vision from Neos Con 2022 to use Neos :wink:

I didn’t make notes, but I think, I reported all bugs from my memory in this thread.

If you ever want to rewrite the UI, you should have a look at prosemirror. It looks like the perfect fit for your node based editing and might solve the inline image issue. There is also phrosemirror to work on the php side with the same schemas. Or TipTap, which is a layer on top of prosemirror - also with a php counter part.

3 Likes