Where did you read this? I don't know if it's better. Better for what? Performance or Security? Instead, I personally believe it's better to use Stored Procedures directly from your ASP, but then, I don't know if there are Stored Procedures in Access. If you are determined to write DLLs (and with Access, you may have to), you'd use Visual Studio to create ActiveX COM objects (which compile into DLLs). Then you register the COM objects with the OS (regsvr32.exe from the command line).
A benefit of using COM objects is that it compartmentalizes your code, and can be reused by the OS easily instead of rerunning the same code in ASP. Secondly, a reason which holds more water for wrapping DB calls in COM objects is security. If someone hacks your web server, and all your code is in ASP pages, they can find out the username, password, and address of your db server (which may also be your web server) and can use that info to get into your database and grab personal info. When you compile the DB connectivity, this information is not easily accessible.
My qualm with COM objects is that every server needs the COM object registered, and re-registered when you re-compile the code. I use a content management system to deploy my code to many production web servers. It is tedious to have to touch every production web server just to register an object.
That which does not kill me postpones the inevitable.