The OCSP responder will only check the status of the particular certificate that is specified in the OCSP request. The responder will ignore the rest of the chain.
A browser may choose to send multiple OCSP Requests in order to check each certificate as it traverses up the chain, but this is currently implemented in a browser-dependent manner across the different vendors, and is further confused by the fact that browsers will cache intermediate certificates served by arbitrary SSL servers and re-use them in chains for different leaf certificates. Some browsers will even try and automatically download up-to-date intermediates from third sources, even when the SSL server is sending an older one. However, it should be noted that in general (at present), intermediate-certificates are mostly not set up to have OCSP information, so it is unlikely that they are OCSP-checkable anyway.
On a related note, there is a new part of the spec that allows for a browser to request multiple OCSP checks within the same HTTP post -- with the intention of allowing the intermediates to be checked along with the leaf-- but nothing yet supports this, and this is likely to only be supported on servers that employ OCSP stapling (Apache 2.4+ etc), otherwise the resultant load on a OCSP responder for an intermediate certificate, without stapling, is likely to make it fall straight over. (With an intermediate certificate signing hundreds of thousands of leaves, imagine how hard it would get hit for revocation requests, without the benefit of widespread support of the distributed caching that stapling will bring).
The root certificates, of course, can't be checked by OCSP. They are signed by themselves, so if trust has gone, there's nowhere to look, and you just need to remove the root cert from the client.