UPDATE (January 16, 2019): The credential management API has been announced. Currently only supported on Chrome and Opera, but looks promising. Google developers have written an article about the specification.
UPDATE (December 28, 2016): another couple of years have passed, and another update. This one will be more focused on two new developments than anything else. See the new "WebUSB & Web BlueTooth" section in the "Full Device API" section. But the answer remains the same.
UPDATE (November 3, 2014): A little over two years have passed since the original message was written, but the answer so far remains virtually unchanged. We are, however, closer to your original goal in several areas.
ORIGINAL RESPONSE:
There would be several ways to do this.
Background
The HTML5 specification has moved to the Recommendation state. This means that HTML5 is pretty much tuned to how it looks. However, I will use HTML5 in the same way that every marketer in the world has decided which is better. That is, I will not talk about HTML. Well, I will, as far as you will use it from the HTML page, but not really. In fact, I will discuss JavaScript (JS) and a horse of a different color . But for all purposes, we put it under the same heading as HTML5, which now decided to call "brilliant and new."
In addition, the points that I discuss will differ in support. Some of them are very browser-dependent projects (for example, implementations specific to Chromium), and some are projects that are more focused on standards, in which there may not yet be browsers that implement or experiment with them. I will try to distinguish between them as I move.
Full Device API
Status: Incoming but Not Ready
The ability to access devices from the browser makes slow but steady progress. Currently, many modern browsers have access to some of the most common devices, such as cameras or gamepads , but they are all high-level APIs. Browser vendors , standards groups, and many Internet-related companies are trying to make web applications as powerful as your local applications.
But the APIs you are looking for are still under development and still a long way off. For your specific case and for the more general case of connecting your web application to most devices, we have a few more years before we can use it. If you want to see what amazing things appear in this area, here are just a few of them that can help you:
- Web Near Field Communication (NFC) API
This, unfortunately, may be dead in the water at the moment. But it seems that initially some people from the W3C (mainly Intel, it seems) looked at adding the NFC API to the network. - Media Capture Streams
The WebRTC team is working on programmatic access to media streams, such as a camera, to integrate things like barcode scanning or other functions. It has reached CR status and is available in browsers , but in itself is less useful. - Web bluetooth
If you have Bluetooth-enabled tools, this API will help you connect to them from computers and devices that could listen and connect. At the moment, the main driver for this is the Chrome team, which includes an experimental implementation, but I would not think that it is ready for use (see the "WebUSB & Web BlueTooth" section). - Webusb
This would allow full access to low-level USB information, including device lists and interaction with them. Same as Web BlueTooth, it looks like this is the current Chrome pet project, but I will not rely on it either either (see "WebUSB and Web BlueTooth"). - Network Services Discovery
If you have other devices or elements on the network that transmit and use HTTP, this API will allow you to discover and interact with these services. There is no browser implementation, but it is in a working draft for W3C.
Mozilla originally promoted some of them due to Boot2Gecko (or Firefox OS). However, since this project has been officially canceled, we do not see much progress from them in these areas now.
However, the Chrome team seems to have decided to dive in and start not only working on it, but also using them in browsers. Which brings us to ...
WebUSB and Web BlueTooth
Like sausages, it's best not to know how web standards are created
-Abraham Lincoln (possible)
There was a bit of noise in this area, it seems that the Chrome team used them as experimental functions and developed their own specification for them. What a great thing! Just maybe not the way you hoped.
Each browser provider and group of W3C members have their own style and contribute to the specification in their own way. The result is usually a pretty decent specification, which browsers have agreed to. But the transition from nothing to something ... is dirty. Very dirty And this is quite a few times. This does not always lead to a good specification (yes, I'm talking about a compromise with Florian ...), but even when this happens, it takes some time.
However, it seems that Google has developed this version of the specification on its own. And, in my experience, Google’s approach to specifications is always a bit ... well ... leaving my personal opinions aside, we say "fanatical." They tend to just dive right into the deep end. And that seems to be what they did here.
I very much doubt that these specifications or implementations will look something like this when they become standards . And there is nothing wrong with that. This part of the process. But I would not rely on this implementation or develop any code or products against it. This is an unprecedented feature on the Internet, and all browser manufacturers will want to make a big contribution to this.
However, this is actually good. One of the things Google often does (for better or worse) in situations like this is to force the conversation, and this can push it forward. And the presence in the browser of a function, even an experimental one, can increase the demand for it. Thus, we can see more progress in this area in the near future.
Phonegap Apache Cordoba. You know for your phone
Status: not fully equipped and only a telephone
Apache Cordova , formerly Adobe PhoneGap , is a way to write your program in HTML, CSS and JS, which allows you to access low-level features like phones and compile on different devices. It would be a way to implement your program, but it would be a phone application, not necessarily a desktop computer. An option to consider, and I decided to mention something.
Cordova already has some of the features listed above, but no more powerful ones like NFC or BlueTooth.
Native-App Solution (for Windows 8)
Status: possible, but dependent on OS and desktop application
Windows 8 offers the ability to create HTML and JS applications. This will allow you to easily access lower-level functionality in the OS through their API . Apparently, it is quite extensive, and you can do a lot. However, you mentioned supporting multiple OSs, and this obviously limits you to one OS.
This is so Flash!
Status: Dying / Dead, impossible as a web application
Flash will not have direct access to the system via the Internet. You can create an AIR application, but that will be a kind of defeat to the goal of creating a web application. In addition, Flash support on mobile devices and on the Internet would seem to be in decline.
NodeJS
Status: it can be a little painful and maybe only as a desktop application
NodeJS and JS applications have been a hot topic in recent years. I did not discuss this in my original post, because I felt that it was not quite there yet. However, the situation has progressed, and it is much closer to being prepared for this kind of thing, and has the support and power of a growing user base. However, for your specific case, I would not recommend using it. It must be local on the user's computer, and due to the way NodeJS (and similar engines) are currently working, it will require a lot of additional settings and settings that will complicate the situation a bit.
This way you can create an application using HTML, CSS and JS with NodeJS or similar mechanisms and have low-level access to what you need, but it should be local and it will take more work than I'm sure you want to do every time you would like to install it for a client.
... where have I been?
So where does this leave us? Well, simple: if you want to use one language / set of code as the basis of the code, HTML / CSS / JS is not the best option ... for now. But they may be someday. At the moment, your options are limited to what you consider the best for your client. Java is the stable option that you have listed, but obviously has its drawbacks. As the network develops, I think we will see many really interesting things that have appeared in the new functionality, but we have ways to go even further.
More reading: