Working on several projects for this kind of scenario, I can immediately tell you that communication with equipment only from the web client will not happen.
Even now, 2 years after it was originally published in the HTML5 glory days, there are still some hardware elements that will simply never be available directly from HTML and / or JavaScript code.
However .... what NOT to say that it is impossible to do
It just means that you have your work cut for you.
First of all, each kiosk will have to install its own web server or some description on it.
I don’t mean that you absolutely need to have Apache, IIS, Nginx or what has ever been installed (although this simplifies the work), but you will need to install some kind of native binary on the platform that has the ability to talk to equipment.
I work a lot in .NET, so in the past I decided to launch a Windows service application and then expose the json endpoint set using something like NancyFX.
This service will run in the background, listening on a specific specific socket.
This service may also be responsible for delivering the actual HTML for the kiosk pages (but that would be easier by serving them from a static server such as Nginx)
Then, HTML should simply use jQuery, Knockout, Angular, or any other infrastructure that allows it to make calls to these Json endpoints to control a different bit of hardware.
A significant part of the hardware, such as the chip and pin contacts, card readers, receipt printers, is controlled from serial ports, so talking to the actual device after you have the protocols is usually very simple.
I know that you said that the HTML bit is not negotiable, but for what it's worth, scripts like this are still prime time for technologies like Silverlight and Flash.
Most of the material Iv'e worked on had a rather mediocre PC assembly, installed on a Windows-based OS, a copy of IIS, and an application layer for applications that run on hardware. IIS then provides one HTML page that launches a user interface based on a full-screen interface based on Silverlight, which can then directly talk to services through RPC and / or WCF.
The whole scheme of things works very well.
If you are working on a * nix system, then you will most likely want to write a bunch of daemons at the service level, and apache with a fashionable monom should allow you to run a .NET interface that runs on a platform other than .NET.