You might consider statically publishing your pages then if that's possible; i.e., don't worry about hooking the web server up to the data directly -- just generate the pages you need from the database every time data is added, then copy (publish) those to the live site by copying the static HTML pages over. There are more sites than you might think that work this way. It depends on how much you need to do against the data; e.g., if you need advanced searching this may not work. Then again, it may if you run a page indexer (many free ones available) against the published pages. This option often looks cumbersome and clunky until you start scoping out the alternatives.

I'd at least line up the pros and cons of the static publish approach if that's at all an option. If not, you have several other options I'm aware of:

• Export the Access data to something you can use as a database on your web server box. If this is simply an issue of a UNIX server not having the ability to host Access, then my first choice would be to import to a native relational DB on the UNIX side. e.g., export from Access to some intermediate format (e.g., CSV) then import that to a true relational database on the other side (e.g., MySQL, Oracle, etc.)
• If you have no DB capabilities on the web server side then you'd be limited to access through CSV or other flat file formats. DBD::AnyData may be useful here.
• Non-MS systems can access a MS hosted Access database via ODBC. There are, for example, ODBC drivers available for many UNIX systems. If you install one of those, you can then use DBD::ODBC to access the data.
• You may be able to use DBD::Proxy to proxy a web server database request over to the MS box running Access. This would also require set-up of a DBI::ProxyServer on the MS box.