Hacker News Reader

Comment by roebk | Hacker News Reader

I've just tried to use this example and it appears that there's been zero consideration to any form of accessible features here.

The show example "button" is a non-focusable div element

  <div class="button" onclick="window.examples['theme-modern']()">Show Example</div>

Once the window is open, the minimise, maximise, full-screen and close "buttons" are spans containing no useful text.

  <span class="wb-min"></span>
  <span class="wb-max"></span>
  <span class="wb-full"></span>
  <span class="wb-close"></span>

The list goes on...

Sure, sometimes accessibility can be hard to get right but it's quite something for it to have been completely disregarded.

View on HN

This would 100% keep me from using this. a11y is my number one reason for using third-party UI elements. Making things work with the mouse is usually easy enough, but for complicated widgets there’s a long tail of subtle accessibility issues that are tricky to get right.

That's true, the good thing about Open Source software is everyone is able to apply their improvements to it :)

I mean I get it, but accessibility is one of those things that can be very painful to add after the fact. If this project is meant to be used in actual applications, they’ve pushed a very tedious task unto outside contributors.

Yeah, retrofitting a component for accessibility can lead to weird behaviors for consumers that have to be checked against.

This is a fine and good statement for many things, but a11y is more of a fundamental architectural & design consideration for projects of this variety. In my experience, a lack of a11y consideration overall is more of an indicator of the overall suitability of the product design for your needs than simply a "missing feature you can add".

Open Source software is great insofar as you can contribute to it in many ways, but applying this logic to all situations is really dismissive. There are many aspects of software projects that are largely or solely dictated by the creators/maintainers of that software, that may be impossible for idle contributors to significantly affect (and even forking can be a gargantuan/unviable option in some cases).

TL;DR: Open-sourcing your software should not shield you from constructive criticism, NOR should it invalidate the advice of informed people recommending against using your software.

The fact that "anyone can add a feature" doesn't excuse the lack of a feature existing _right now_, especially considering (as other commenters point out) accessibility is very difficult to retrofit. Not to mention, accessibility should be a top priority for any user-facing software, and the fact that it was utterly neglected suggests there may be other basic flaws.

I tried to address this same issue when I created my website. I don't really know how accessible it is, but you can navigate with the keyboard.

https://victorribeiro.com/

It's an open source project which has been developed only for 21 days.

It calls itself a professional window manager. So it shouldn’t be surprised to be judged by that standard.

> It calls itself a professional window manager.

...that's in development. Professional things are not allowed to be in development?

Do you go around your town criticizing people that are in the process of constructing office buildings, because they don't have the wheelchair ramp installed yet?

Perhaps if you care so much, you can lend a helping hand...

This isn't a case of having a wheelchair ramp that hasn't been installed yet. This is more like there's no wheelchair ramp, and while there's room for one out front, they've already done the landscaping there.

Pffft. Right - because code is not completely mutable at any time during development.

Have you considered that the analogy breaks after the obvious bit?

How does the analogy break? Do you think you can't tear up landscaping? To add a ramp you have to do work to undo the existing landscaping, install the ramp, and then redo the landscaping in a way that fits with the ramp.

And then pee on the floor and do jumping jacks, run in circles, then read a magazine, then install an upside-down lectern in the living room only to realize... you forgot the television.

God save us all!

The analogy breaks because code is able to be changed at any time almost as easily as writing new code. There is no such thing as landscaping in code. It's all easy to change.

You seem to think that it's completely free of effort and cost to change code. That is absolutely not the case. Some things can be incredibly difficult to add in to a codebase that wasn't designed to expect that kind of change.

> Some things can be incredibly difficult to add in to a codebase that wasn't designed to expect that kind of change.

In a 3 week old code base? Please... You can write the entire thing over again in a week and add what you want during that time.

The commenters here should do that too! It would probably take less effort than bitching about someone's side project that they'll probably never even use here on HN.

Tearing out code that has already been written (which would be required here) is analogous to tearing out landscaping that has already been installed. You either don't understand accessibility, analogies, or both.

But why start with

    <div class="button">

instead of just using an actual html button?

`role=“button”` can be faster than overwriting the crappy default button styles for people who can’t spare 15 seconds

Reply on news.ycombinator.com