Screen-reader testing is a bit more challenging at first. On the plus side, high quality, free screen-readers are readily available, such as NVDA for Windows, and Voice Over on Mac. If you follow my advice, there are not a lot of controls to learn. The tricky part is just getting used to the experience.
I still remember the first time I tried a screen-reader. It was very disorienting. It was hard to understand what was going on and how your were supposed to interact with it. For someone who is used to a visual experience interacting with the web, it is just completely foreign, and possibly panic inducing.
Luckily, this feeling fades pretty fast after a couple sessions. My advice to ease yourself into it is to start with a very simple, preferably already quite accessible page. If you are a developer, you might want to set up a simple page yourself with some basic content and a couple active elements. IF you need an accessible (though not necessarily simple) page to start with, visit a government website. They usually have at least basic accessibility in place already.
Once you’ve chosen a sample page to start with, take a moment to find out how to slow down the speech rate of your chosen screen-reader. The defaults are fairly fast, and “native” users tend to listen at a rate that is just too fast for even experienced occasional users to understand, so make it easier on yourself by starting with a slow rate of speech.
To begin, load your chosen page, and simply let the screen-reader read the page from top to bottom. Try to follow along with the reader with your eyes, seeing how various features and content of the page are rendered, and in what order. It might be tricky at first, so don’t be afraid to reload the page and start from the top again if you get lost.
This process will give you a feel for the nature of the screen-reader experience (and will probably justify to you the importance of accessible webpages for non-visual users).
When you get to real testing, it will often be convenient to have more control over the reading of the page, and the default way to do this is “arrowing through” the page. All screen readers will have line-by-line, forward and backward controls. For example, for NVDA, these are the up and down arrow cursor keys. This technique gives a fine grain of control to see how things are read, and allows you to go back and reread a line if you missed something. This is also the lowest common denominator of how real screen-reader users will read a page, especially new, relatively inexperienced users. Most of your testing will use arrowing, since it is also the most thorough way to check all the content in the page methodically.
Another useful command to learn is the one that most screen-readers have that give a list of headings and links in the page. (On NVDA, the default command for this is Insert+F7). This gives a quick way to check out how well-organized the page content is, if the links have sufficiently descriptive text to understand out of their context, and sometimes brings to light structural problems in the page.
As with the keyboard-only testing, you will want to make sure that all the links and other active elements work, and typically these are triggered with the same keys as you used with the keyboard-only testing.
For someone who just needs to be able to test pages or apps for accessibility, I would recommend resisting the temptation to learn further features of your screen-reader, for a few reasons. First, it makes is simpler to learn. Second, it is a more thorough way to test the content and functionality of your app or webpage. Third, it mimics how a beginner, who will have the hardest time navigating, will actually be using your product. And fourth, if testing works with this simple method, the chances are that the more advanced features will also work correctly for advanced users.
So that is all you really need to know to get started with screen-reader testing. With a bit of experience using these techniques, you will be able to get a very good idea of how accessible your product is, and what needs to be done to improve it.