There are plenty of cheap 802.11 APs and client cards out there with broken multicast* support, especially when encryption is enabled, and especially especially when WPA2 Mixed Mode (AES-CCMP simultaneously with TKIP) or 802.11i TSN (AES-CCMP and/or TKIP simultaneously with WEP) is enabled.
*Note: In 802.11, broadcast is a subset of multicast: it's a multicast that goes to everyone. So when I say "multicast", think "multicast/broadcast".
On 802.11, multicast is trickier in the AP -> client direction, because it has to be sent at a lowest-common-denominator multicast rate, it isn't ACKed or resent at the 802.11 layer, and if you have WPA or WPA2 encryption on, it has to be sent encrypted with a different key (the group key), and if you have WPA2 Mixed Mode or 802.11i TSN on, it has to be sent not only with a different key, but with a different cipher (a lowest-common-denominator cipher; TKIP in the case of WPA2 Mixed Mode, and WEP in the case of TSN).
One quick way to see if it's just multicast problem is to manually add static ARP entries on each machine, so they know the "IP address -> wireless MAC address" mappings of each other, and then see if you can ping. ARP uses broadcasts, so broken multicasts on an 802.11 network breaks the ability of a wireless client to receive ARP broadcasts when other clients are trying to look up the wireless client's MAC address. Without the ARP mapping, the ping frame can't be addressed at the 802.11 layer, so it can't be transmitted.
If static ARP mappings fixes it, try temporarily turning off all wireless encryption, then delete your static ARP mappings and try your test again. If ARP works this time, it's a sign that multicast is not completely broken on your 802.11 equipment, it's just broken when encryption is on.
About now, some might be asking, "But if broadcasts are broken, why did DHCP work? DHCP uses broadcasts!", and you're right that DHCP uses broadcasts, but in DHCP only the messages from the client to the server are broadcast. In the other direction, they're usually unicast. And it's only in the to the client direction that multicasts are tricky in 802.11.
Check with your AP and client card vendor for firmware and driver updates. Always buy Wi-Fi certified 802.11 gear, because the Wi-Fi certification testing specifically tests to ensure multicast works even when crypto is on. Please also "name and shame" the vendors of the AP and client card(s) in question.
When multicast is broken between an AP and a client, I can't think of an easy way to tell if the fault is with the AP or the client, other than process-of-elimination, by seeing if other brands of wireless clients have the same problem on that AP, and seeing if that wireless client has the same problem on other brands of APs.
The more advanced way to pin the blame on one end or the other is to use another machine that's not part of the test, but has an 802.11 card, to do an 802.11 monitor mode packet trace, starting from before the wireless client associates. Someone well-versed in 802.11 and WPA[2] key handshaking and the like can probably analyze it and find where to point fingers.
I do most of my networking work on Macs, so I can't walk you through getting 802.11 monitor mode packet traces on other platforms, but just in case you have a Snow Leopard (Mac OS X v10.6) box around, you can do:
sudo /usr/libexec/airportd en1 sniff 1
[...run your test...]
^C
...to do an 802.11 monitor mode capture, via en1, which is typically the built-in AirPort card on most Macs, on channel 1. Modify that if your AirPort card is not en1, or if your AP is not on channel 1.
Or you can do:
/System/Library/PrivateFrameworks/Apple80211.framework/Resources/airport -z -c1
sudo tcpdump -I -y IEEE802_11_radio -s0 -w monitorModeTrace.pcap
[...run your test...]
^C
(The -c1 argument to the airport tool puts in the interface on channel 1; modify that to the channel your AP is on.)
Or you can run Wireshark, tshark, etc., but on the Mac you'll still need to use the airport command to set the channel and to force a disassociation.
Best Answer
Ping usually uses ICMP whereas web access uses HTTP over TCP. So it is possible that some firewall or filter is blocking one but not the other.
Are you sure the webserver is running, is listening on the port you expect (80?) and does not have any allow/deny rules that are blocking access?
Are you using a hosting provider? Do they have a help desk? Are they still in business?