First, designing an app for a client without finding out ahead of time what can or can't be installed is probably an error on your part. I could try to pull some punches here, but by going in blindly, you screwed the pooch.
Second, there is an old rule that says if the only tool you have is a hammer, everything needs to look like a nail. If all you have is an Access database, you need something that will run Access databases. MS Access Runtime does that. MS Access does that. Very little else will do that. So if your client doesn't want Access on his system, your product is something he cannot use. However, I would go back and look at any contract you might have signed to see if you have any wiggle room regarding Access Runtime, because CLEARLY for your client to run your app, he would have had to install something on his system unless he directly asked for a web-based app in the first place.
Third, converting an Access app to a web app is possible but essentially you need some other DB as the back end because (so far as I recall) the Access DB engines JET or ACE (depending on the version of Access) don't play nicely with web services. At least I have not heard of a good situation for that. So you COULD convert the table & relationship structures to something else like SQL Server or SQL Lite or MySQL or ORACLE or something else and then have a web front-end that can correctly access the DB content for you. But you would be redeveloping from scratch and AGAIN would have the issue of requiring your client to install the DB engine in question. And even if you found a way to make the web interface work with JET or ACE, you would need to install either of those DB engines on your client's machines.
Fourth, you could, if you had the resources, build this app on your own system as a web app and then host it for your client - but app hosting is not a trivial operation and involves such things as availability clauses, plus the requirement for backups, uninterruptible power supplies, and a service desk function.
I'm not trying to be negative here, but I AM trying to be realistic. You have painted yourself into a corner. I think your best shot is to convince your client that Access Runtime is necessary for his app to work and his reluctance to install it forces you into a MUCH more expensive solution. Then ask him if he is willing to pay extra for the more complex solution that avoids your simpler solution. So think of this post as strategy advice.