Audits are to Databases what Lot Traceability is to inventory control. They are nice, but you are best served by running away unless you have to implement. For Audits, the questions are still out there, what are you trying to audit? Is it just an update audit flow, or a read/write audit? Where are several ways in which to do this, triggers either in the database, or the access program. Both have their problems, database triggers will always create an audit entry, but for most access / web based programs the user accessing the database is a control user of the program, and not the user logged into the program. For an access/runtime audit, you can get the information about which user changed what, but you have to do all of this manually.
Goes back to, "Do you want to shoot yourself in the right foot, or shoot yourself in the left foot? Enough to say you WILL shoot yourself in a foot."