They are related in that UAC relies on the existence of ACLs (and all the related security apparatus) in order to function.
UAC works by removing (technically speaking, disabling) the Administrators token from non-elevated processes. This means that if the ACL for a particular file or folder only allows access to Administrators, non-elevated processes won't have access. That's why an installer can't write to Program Files without elevating first.
See this article for more information about UAC.
In particular: "When an administrator logs on to a computer that is running Windows 7 or Windows Vista, the user is assigned two separate access tokens. Access tokens, which contain a user's group membership and authorization and access control data, are used by the Windows operating system to control what resources and tasks the user can access."
I suppose you could argue that UAC depends on the Windows authorization model, of which ACLs are only a particular component, and that therefore UAC is not related to ACLs. I don't think that's a useful way of looking at it. Let me put it this way: if there weren't any ACLs, UAC would be pointless.
You should also read this article which addresses some common misconceptions about UAC, and in particular the misconception that it is a security feature: "The primary goal of UAC is to enable more users to run with standard user rights. However, one of UAC's technologies looks and smells like a security feature: the consent prompt. Many people believed that the fact that software has to ask the user to grant it administrative rights means that they can prevent malware from gaining administrative rights."