Accessibility on Hackernoon.com

As a web accessibility advocate and software developer, I can’t refrain from asking what are the plans around accessibility? Currently, it’s in an abysmal state and as someone who occasionally posts accessibility related articles, I’d like to post them on a publishing platform that is actually accessible. :slight_smile:

I ran a quick AXE test and the results are worrying me quite a bit:

But, having WCAG 2.1 AA compliant code of course is not everything, so tried using the site with keyboard only. Failed miserably again. No visible focus, no tab navigation, no skipnav, no nothing.

At this point I didn’t even try using a screen reader any more. It would only make me cry.

So, what is the plan? Generally I advise people to design and develop accessibly so the costs are kept at a very minimum. With so much already being built inaccessibly, fixing everything after the fact won’t be an easy task. Can I help in any way? It would be great to see this resolved as a priority.

2 Likes

We’re working on it. Accessibility is definitely important to us but we also need to balance accessibility with everything else we’re trying to bake into 2.0. What are the most important accessibility issues you are seeing?

1 Like

@David and team. , @attilavago brought up an important point. Accessibility should be an important design/development fact to have in mind when creating an application. I also believe this app should be as accessible as possible to be able to reach readers of all sorts. I believe this would be beneficial for Hackernoon in a big way. It could be a way of saying: “I care about my readers and want to provide the best content to everyone”. Not to mention by 2021 All public facing websites must be compliant with WCAG 2.0 Level A & Level AA (Not including 1.24 or 1.2.5).

Thanks for bringing this up @attilavago . I’m also working big time with accessibility at work, so If you need an extra set of eyes, I’ll be around.

1 Like

Hi @Dane thanks for getting back on this on a weekend. From where I’m standing, accessibility should not be looked at as a feature. The moment it is seen as a feature, it becomes an item on the backlog. Seen this way too many times. Once it’s on the backlog it gets de-prioritised. @agnelnieves hit the nail on the head when saying accessibility must be part of the design and development story. I don’t see it as something that has to be “baked in” but rather something without which one simply cannot bake. Accessibility improves the UX for everyone and improves the compatibility of the app with a lot of devices. As if that were not enough of a reason, creating an inaccessible site is well… kind of a crime. A crime against 1 billion people on average, because an inaccessible application is equal to the deliberate act of social exclusion and in certain cases can result in lawsuits as well.

To answer your question @Dane about what parts of accessibility I would like to see, I can only say an app or site either is or not accessible. It cannot be done in parts. I would like to see Hackernoon.com meet the WCAG 2.1 AA criteria at least. It’s not that difficult. Some design adjustments, semantic HTML can already go a long way. Where it makes sense use aria properties especially for live regions. Avoid modals, popups and please don’t disable browser focus. It’s there for a reason. Feel free to reach out for more granular advice, or if your developer team needs support, I am happy to offer some of my time to lend a hand in any meaningful way I can.

1 Like

I think it should have Product category

1 Like

Sorted.

Any updates on tackling accessibility on Hackernoon? So far this has been the reason why I avoided publishing on the new platform. @Dane @David