ODBC abstracts the database from it's physical location, and makes it available over a network. Basically, it makes it so you can work locally or remotely with a database without worrying about the details. It also abstracts the details about exactly which type of database you are working with (to a degree). Thus, you can build an application with Access, import the data into SQL server, and just re-assign your ODBC connection, and your system will work almost identically, although faster. The only information your application needs is the DSN (Data Source Name), which is a unique name you choose for every ODBC connection created.
The thing to remember is that, in order for a webserver to run an ODBC-connected database, there has to be a machine somewhere with the database engine itself. Here are a few different scenarios:
1. You have an dedicated SQL server machine, which hosts your database. Your webserver merely opens an ODBC connection with that server, and thus the database is available as if it was hosted on the webserver.
2. Your webserver has Access installed on it. You place a .MDB file anywhere on the server, and create a file-based ODBC connection, which your application can use just the same as any other ODBC connection.
3. You have one of the above two scenarios, and suddenly you want to move your database to another machine. You simply move the database, and change the ODBC connection details on your server, and your application continues working transparently, since it is still talking to the "same" ODBC connection on the server.
In all of these scenarios, your application never talks to the database directly. It just talks to the ODBC connection, and ODBC acts as the broker, making the actual "deal" with this or that database.
So, in answer to your original question, IF the webserver has Access installed on it, then you can do what you want. If the webserver is just running Windows NT and IIS, then it doesn't have the database engine to run Access directly. However, the server does have the ODBC engine itselt, so if you can find another machine with Access on it, then you can simply place your .MDB file on that machine, and open an ODBC connection between the server and that machine.
I suppose a theoretically possibility is to export your database as a self-running executable application, in which case it would contain the Access run-time libraries, and then it could be it's own self-contained database engine, and theoretically share an ODBC connection locally on the server. I have absolutely no experience messing with that, however.