Hi and welcome to Network Engineering
As I understand, in ARP spoofing (of any kind), there's a man in the
middle that intercepts frames from a sender (Alice) by masquerading as
a receiver (Bob)
The "man in the middle" and "interception" bits are not quite true for the first step. However, a successful ARP spoofing attack and some source-IP faking can turn an ARP spoofer into a man-in-the-middle.
One does not need to man-in-the-middle style intercept (and alter) ARP packets for an ARP spoofing attack [1]. It is sufficient to send (a burst of) fake ARP response packets (or gratuitous ARPs) to a client that just tried to find another system's MAC address (usually the default gateway). If successful, the victim(s) will henceforth use the attacker's MAC address as DstMAC address in their frames which are to leave the local subnet.
By adding some sourceNAT (using either its own or unused IP addresses from the local subnet as srcIP) when sending these frames back out towards the real default gateway, the attacker can ensure that response packets are also sent towards his host. Alternatively: by sending another burst of fake-ARPs towards the default gateway or router, to trick it into accepting a a wrong MAC address for the victim's IP).
Since now both directions of traffic are seen by the attacker, the attacker becomes a man-in-the-middle, and this opens the path to all kinds of evil things, including intercepting and manipulating of upper layer traffic.
In a Wireless LAN, this is possible without decrypting any other station's Wireless traffic, just as long as the AccessPoint's or WLAN Controller's settings permit client-to-client traffic for the given SSID.
This is precisely one of the good reasons to block client-to-client traffic in a public hot spot.
[Addon1 after comment:]
But can the attacker read the information of the frames?
The above assumes that the attacker can successfuly join the Wifi SSID. Any client-to-client traffic in Wifi infrastructure mode (as opposed to ad hoc mode which is barely ever seen anymore) is always hairpinning through the access point.
In that, the pairwise session key is only of relevance to the AP and the given client (attacker or victim); so actually, the AP de/re-encrypts both the frames from/to victims (with key material negotiated with each individual victim) and from/to attacker (with key material negotiated with the attacker).
The attacker will see frames coming from the victims, but encrypted with AP/attacker's pairwise key - no extra effort needed to decrypt them.
Different story if the ethernet frames themselves carry encrypted traffic like IPsec or something with TLS/SSL - but that's further up the stack and out of scope of this question.
[/Addon 1]
[Addon 2]
A device claiming to be able to perform ARP spoofing an MitM attacks in a Wifi network must first be able to join that WiFi (by legitimate means or forced ones), and it must be able to disable/circumvent the SSIDs client isolation feature (if active). Else, there's little chance to play an active role in a WiFi network. Or it may be cabled on a LAN segment or VLAN which is bridged with that Wifi SSID, but then it's just ARP spoofing as if in a LAN, nothing specific to a WiFi.
[/Addon 2]
[1] of course, if the attacker sits in the network path between his victims (usually between end system and default gateway), ARP spoofing can be performed as well. But in that scenario, it is of no interest anymore - both directions of traffic are flowing across the attacker's host; packet interception and manipulation becomes straightforward.
