Should I consider every mobile smaller than 768px a touch device?

Question

I have been making a website which behaves differently on touch device than desktop. The main difference is that most of the hover effects are changed to clicks on touch devices. To check if user agent is a touch device I use this in javascript:

var yesIfTouchDevice = (('ontouchstart' in window) || (navigator.MaxTouchPoints > 0) || (navigator.msMaxTouchPoints > 0));

if(istouchdevice) {
  // change hover to clicks
}

Then in css I assumed that every user agent below 768px would be a touch device. I made the layout presuming that. E.g. I have a toggle button that shows menu on tap. Further I have many other things that show pop up and other hidden layer only on tap(touch event).

Just a few minutes ago the thought occured that there are many mobiles that are not touch enabled, like Nokia Asha and N series and many more which I don't even know. My question is:

1. What is the market share of non touch mobile browsers? How many percent users use those browsers?
2. I have made my whole website with bootstrap assuming touch functionality for small screen devices. Does modern day html css best practices suggest making website only for touch enabled mobile devices?

Edit: Upon listening to the suggestions I have decided to optimize for non-touch mobile devices too. But I am not sure how they mimic mouse behavior in general. I am guessing that elements that are focusable can be selected and clicked. So,

3. Should I make all my elements that work on hover, e.g. the navigation, focusable with tabindex = "1"?

I have been testing my site on opera mini browser in Kemulator and found that it reloads page when I click on navigation and some other layers are not shown, e.g. the bootstrap modal pop up.

4. Does opera mini browser not support javascript well?

Answer 1

You can use the code from detectmobilebrowsers. Just replace the url http://www.detectmobilebrowsers.com/mobile with the url for the mobile webpage. This is a direct link to the javascript code. Just change the file extension to js and everything works.

Answer 2

1. What is the market share of non touch mobile browsers? How many percent users use those browsers?

We don't have this data. But based on current market share of OS and devices user share, it hardly reach 1%. But the main concern is not because of non-touch mobile devices. Browser windows are not always maximized, user can decrease thei width even < 768px. ie. Use side-by-side browser and a notepad on a 1400 x 900 resolution.

2. I have made my whole website with bootstrap assuming touch functionality for small screen devices. Does modern day html css best practices suggest making website only for touch enabled mobile devices?

No. Current suggestion is responsive design using mobile-first approach. Using mobile website apart duplicates code, design, maintenance and expenses. It also affects SEO and traffic analyses for business purpose.

Should I make all my elements that work on hover, e.g. the navigation, focusable with tabindex = "1"?

Yes and no. All clickable elements (buttons, links) and input form should be object of accessible navigation, but you do not necessarily need to set tabindex for all clickable elements to make then "focusable" element, the browser will do it as default ordering by appearance in code. Use tabindex to enforce your navigation links flow, if default order doesn't make sense to you or if you want to make sure you will have corrected flow.

4. I have been testing my site on opera mini browser in Kemulator and found that it reloads page when I click on navigation and some other layers are not shown, e.g. the bootstrap modal pop up.

Does opera mini browser not support javascript well?

No. As well as modern CSS. Opera Mini reduces interactivity due to its nature of using a proxy to compress page resources.

Opera Mini is more popular in Africa, Middle East and Eastern Europe. If these region are not your user focus, I would suggest you to not spent time on make website fully work on Opera Mini.

Answer 3

What is the market share of non touch mobile browsers? How many percent users use those browsers?

This is generally region dependent so it depends on your audience. You can get some idea from

https://deviceatlas.com/device-data/explorer/webusage-by-country/traffic/mobile/country/us/type/browser_name

http://gs.statcounter.com/#all-as-ww-monthly-201610-201612-map

But in my experience these are not very helpful because a lot is determined the type of customer your product focusses unless it is a very widely adapted product on e.g. On an niche e-commerce site selling high value stuff you will find Safari prominent. So before solving the problem if you can collect some data (if you have existing product) or ask in forums/fb groups to people who have a product in a similar domain, it will help you in prioritizing, because building is a smaller issue than maintaining it.

I have made my whole website with bootstrap assuming touch functionality for small screen devices. Does modern day html css best practices suggest making website only for touch enabled mobile devices? Edit: Upon listening to the suggestions I have decided to optimize for non-touch mobile devices too. But I am not sure how they mimic mouse behavior in general. I am guessing that elements that are focusable can be selected and clicked. So,

If you want to cover wide range of browsers use https://modernizr.com to detect features and respond accordingly or have fallback interactions. Caution, it's always not a good idea to pull a library if you want only few features, so see your use cases. On the other hand the advantage is it keeps getting updated.

You can see the list of touch (and similar) events fired by different browsers here http://www.quirksmode.org/mobile/tableTouch.html#link1

For list of apple non-touch events take check this https://developer.mozilla.org/en-US/docs/Web/API/Force_Touch_events

Similarly you will have to dig for event lists for browsers which you want to support.

Should I make all my elements that work on hover, e.g. the navigation, focusable with tabindex = "1"?

For tabindex what Andre suggested is right (have the right order for important elements, which should be done at testing stage).

Check this to get an understanding when to avoid and cases where it can create an issue. There are more than the ones listed here, so do a good research if you are playing too much with tabindex.

https://developers.google.com/web/fundamentals/accessibility/focus/using-tabindex

I have been testing my site on opera mini browser in Kemulator and found that it reloads page when I click on navigation and some other layers are not shown, e.g. the bootstrap modal pop up.

Does opera mini browser not support javascript well?

In most cases Opera Mini processing is done via Opera servers, which often prevents JS from working correctly.

These are the workarounds for some features, for which you can refer to https://operamini.tips/#/

All being said, still I would suggest, do a good target user research, and from there prioritize your list of support for your initial versions. It may require investment of time and maybe some money too but it is totally worth it. Then improve on the shortlisted ones till you are able to remove major bugs, and when you have bandwidth then attack the next part of the list. Having an approach of supporting too many browsers/devices/screens at first will take you down the "support labyrinth" from where you will be stuck with removing bugs everywhere, and feature development will go out of focus.

Also integrate GA analytics (or any other) well and attach events to major interactions, and keep monitoring according to screen sizes, device and browsers. e.g. Opera Mini gives me 0 events in some pages and that raises an alarm. Sometimes it may not be 0 but a low ratio of users who interacted /users visited. You can attach events with scroll, field select etc. Prioritize first on major features of your product, track, choose what to focus on, improve, test and then move to next part. So basically this will form a matrix of features with browsers/screen sizes and then prioritize accordingly depending on your traffic type.