I'm not sure that you want to know.
There is nothing built-in for this particular metric, but obviously you could run a trace or extended event session, and analyse the queries being executed. But it would create a bit of overhead. And it may not give the right number anyway, see below.
Moreover, I don't think this is a particularly meaningful metric. Let's say that you have two tables both the size of 1GB. One is being queried 100 times a second, but they are all point lookups on the clustered index key. The other one is only being accessed once a second, but that's a query that requires a full scan of the table. The latter table is taking much more resources from your server.
And what is an access. Say that you have a query that goes:
SELECT ...
FROM A
JOIN B ON A.col = B.col
and the query plan is a CI scan of A and a nested loops + CI seek against B. Say that there are 100 rows in A. Technically, that are 100 accesses to table B. Change the plan to be a hash join instead and it is only one access.