Hacker News Reader

Without hard data, this is pretty meaningless. If I were to visit a site that didn't work correctly in my browser, I would close the tab and never give it another thought. I would certainly not take the time to write a complaint.

> I doubt this is the case since the users are keen and vocal. I get messages almost daily from them telling me the features they want to see.

Maybe existing users (and even for that, I'm skeptical), but how many potential users did you lose because they couldn't even open your app?

I'm not saying you are wrong, just that "users didn't complain" != "users weren't affected".

>If I were to visit a site that didn't work correctly in my browser, I would close the tab and never give it another thought. I would certainly not take the time to write a complaint.

And I wouldn't miss you.

I can make the service better faster if I don't support the lowest common denominator. I'm sure I'd lose more users if the website was bloated with fallback code and my development speed was such that features are a year behind where they are now.

But dropping support for certain browsers/clients without having data on how many of your customers would be affected is silly, IMO. You might decide to drop support for IE 11 because you want to use CSS Grid without hassle, but then it turns out that 10% of your users use that browser! As with everything, you have to weigh the tradeoff, but you can't do that if you don't have the data to begin with.

> without having data on how many of your customers would be affected is silly

You're making the assumption I don't have and use data like that? That's an incorrect assumption.

Sorry, you are correct, I made that assumption. It seemed implied by your use of user complaints as a metric of success—I assumed that was the case because you didn't have hard data, so I apologize if that's not the case.

Not a problem at all. I place high value on being available to users of my website. I reply to each and every message. Perhaps it's a bit unusual for someone to talk about that before the numbers.

It has been my experience that I've gained more valuable insight from talking with users than I have from the numbers.

But, as a little Latina girl once said, why not both?

I think the other person was talking about quantitative data (e.g. from Google Analytics), not qualitative data from customer conversations / complaints.

Yes. That's also what I thought. I'm not sure why you think I thought otherwise.

I completely agree with this sentiment.

I absolutely hate the "does it work on ie6".

The time you spend dealing with old browsers is never returned in profit. I had one customer (ie10) in 4 years, and losing him cost me and made me nothing.

How does your site sound/read in a screenreader like NVDA? [0]

0: https://www.nvaccess.org/

That's a really good point, and it's one of the drawbacks of designing a website for the 95%.

I haven't tested myself (I'm just one dude - there's a lot I'd like to do but haven't yet), but I see no reason why it wouldn't work well. I try to design semantically and everything is rendered server-side.

But, in reality, I don't think this is the kind of website that would be usable for a blind person anyway. There's not really anything to read. There would be much better ways for a blind person to get information than using this website.

Vision impairment is a spectrum, so someone who can see to some extent may be using a screen reader to assist. People might be using your site at 150% zoom, etc etc.

One thing you can do is put a note somewhere easy to find that says "if you require assistance using this site, email someone@domain.org". Sites that I've worked on also had a phone number here but I understand that's an edge case.

You also mentioned alternative ways to get information - if there's ones you can link to (without linking to a competitor or whatever), there's no reason not to provide links.

Hi voltagex, thank you for your input.

I don't think this is the kind of website where I "help someone to use it". Instead of speaking in the abstract I may as well show you so you can see what I mean:

https://pricehipster.com

As you can see, the whole point of it is designed around quickly glancing at prices. And I don't think it makes sense to tell people other places they can find prices if they can't see well enough to use this website.

Okay - that makes sense.

It's been a while since I looked at things like this but have you done simple stuff like check whether the colour contrast ratio [0] meets WCAG standards?

What about making the orange highlight work when tabbing through the website with the keyboard?

What about having a Skip Navigation / Skip to Content link? [1]

0: https://webaim.org/resources/contrastchecker/

1: https://webaim.org/techniques/skipnav/

Yes I keep those things in mind while developing. I may have missed one here or there, especially in any code from my early days of development.

Thanks for the link about "skipnav" I haven't heard that term before. I don't really see how that can fit in, though? I guess the category links right at the top of the page is the closest concept?

It doesn't make sense to skip down to item number 200 since there's no way to know what's down there. Best to look at items 1-199 first. That is the same for all users.

It's exactly to skip to the main block of content - every item in the nav menu may be read out individually (or at least needs to be tabbed through) otherwise.

Oh I understand now. It's skipping the menu itself. I don't know why I misread (skimmed) the link you posted. Yeah, I can see why that's useful. I'll add it to my to-do list to look more into that. Thanks!

I find their recommendation skipnav somewhat ironic - pages on that site with any sizable contents don't show any actual content until after the fold on my macbook, e.g. https://webaim.org/techniques/css/invisiblecontent/ .. the entire first page consists of various forms of navigation.

Haven't tested, I intend to make it possible. Thank you.

I haven't checked recently, but JAWS [0] is probably the dominant screenreader still - NVDA is the open source alternative. Ideally you'd test in both

0: https://www.freedomscientific.com/Products/Blindness/JAWS

Edit: using a screenreader effectively is a skill in itself. There are consultancies around accessibility testing. I am not affiliated with any of them.

> If JavaScript is disabled I just show a message saying the site needs it.

We don't complain, we just go somewhere else.

And I don't complain when you go somewhere else.

Good to know, thank you.