Our site does't work with js disabled. Serious question: is it common for folks to disable js?

vue is used only for the web app. No js frameworks used in the chrome app.

It's not common. My site with hundreds of thousands of users has been using React/Vue for years and I've never had one complaint about JavaScript.

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

I also only support modern browsers and haven't had a complaint for 3 years.

About 3 months ago I completely dropped support for any browser that doesn't support CSS grid (no more IE 11!). Again, no complaints. This one is more "brave" but I use Modernizer and show a clear message outlining all the required features the user's browser doesn't support and why they would want that feature in a browser. There's a link to a website to help them find a modern browser on their platform.

Edit: I realised that based on what I said you could argue that users are annoyed but I'm just not aware. 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. The last time this had to do with browser support was one message 3 years ago about IE9 not supporting the TLS certificate or something. They were forced to use IE9 at work.

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.

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.

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.

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 [email protected]". 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.

Well for what is worth, I had been thinking on the idea for a while after growing tired of so many scripting and tracking everywhere, and I felt encouraged to make the jump and disable Javascript after reading this comment in HN (thanks bmurphy!):

> The single best improvement I've made to my mobile browsing experience in years wasn't getting a new faster phone, it was installing Brave and disabling javascript. [1]

To be honest, (s)he was right. But at the same time, it's disgusting, and plainly bad, to see how much of the Internet is _broken_. Which by my definition means requiring JS even to show some text and images on a web page.

I understand that more advanced features might require some scripting, but come on, I'm pretty sure that's not the case for printing some good old letters and pixels on a browser window! And still, lots of places seem to not know how to do it without dynamic code all around. (I'm not talking about this specific site, in any case. Just felt like ranting.)

[1]: https://news.ycombinator.com/item?id=14153588

Graceful degradation:

https://en.wikipedia.org/wiki/Fault_tolerance

Progressive enhancement:

https://en.wikipedia.org/wiki/Progressive_enhancement

> Our site does't work with js disabled.

Then please have a noscript tag.

> Serious question: is it common for folks to disable js?

That's not the only reason you'll find for JS being unavailable.

Windows Updates has managed to disable JS in various situations across both Edge and IE over the years due to tightening security policies.

Chrome has had V8 crashes over the years, as has Firefox.

The browser might be misbehaving, but rarely will the user attribute it to the right place - your site will get the blame.

It's best to use some sort of server-side rendering so you get the best of both worlds.

JavaScript-only is not friendly for SEO.

Agreed! We're working on prerendering some pages -- https://ssr.vuejs.org/#why-ssr .

I usually leave it enabled, I just tested it when I viewed the page source and saw very little was there beyond JS. I guess I come from a different time where you used as little JS as possible/was required.

I'm also not familiar with vue so I was trying to work out if it was used to build your web page or the actual chrome app. The web page is fine but I just wasn't sure where vue came into the picture for such a simple site.