Quick Checks for Web Accessibility
In the following, I want to show a few test options that can also be carried out by technically inexperienced people. All you need is a browser and patience.
Article Content
Keyboard usability
An important pillar of accessibility is keyboard usability. In the first step we put the mouse aside.
The core of the keyboard operation is the tab key. With this button you can jump from element to element. So in the first step we try to jump to all clickable or fillable elements of the website. Each clickable element should change the tabbed element. This is usually an outline, but it can also be a change in color or an underlining for links. A purely color change can be problematic for color-blind or visually impaired people. Either they don't notice the change or they can no longer read a link because of a bad color selection. Basically, it makes sense to convey the information in two ways: an underline and a color change, a color change and outline, and so on. In the following I assume that the tabbed state is made clear as a frame.
With the return or space key we should try to activate links, buttons and everything else clickable. If there's no clearly visible change when tabbed, or nothing happens when you click, we've already found an accessibility issue.
Also, the tab shouldn't get stuck anywhere on the page. Hopefully, when we reach the last element on the website, the tab will jump back to the first clickable element on the webpage or the browser's address bar. If we press Shift and Tab at the same time, we can tab backwards.
We now grab the mouse - for once - and check whether we can see a clear highlighting of clickable elements. This is primarily for the visually impaired or people with restricted mobility. They may use the mouse, but they are much more insecure than sighted people. You must be able to clearly see that an element is clickable and you need a sufficiently large click area. A color change for links or form elements, a frame or something similar is usual here.
We should also pay special attention to elements that are displayed dynamically, i.e. without the page being reloaded. These are, for example, dynamically opening menus. If we - still with the keyboard - come to the corresponding link, the menu should expand and stay expanded after pressing return. We can now go through all the links in this expanded menu item and should also try one of them.
Forms
In the next step we should take a special look at forms. First of all, let's tab across the form. The tabbing order should be logical, that is, the elements should be tabbed the way they are arranged on the website. The weirdest stuff can happen here, for example the cursor jumps from selecting the address to entering the street name and bypasses entering the person's name. Once you enter the city, the cursor jumps to the first name. Not only is this confusing, it's annoying because we're so used to a certain fill-in pattern that we find such behavior disturbing.
After the correct tab order, we check whether we can activate or deactivate all select boxes. We'll do that with the spacebar, not return! Each checkbox and radio button should only be selectable with the keyboard. For drop-down lists, you should be able to use the cursor up and cursor down keys to select the option you want. If you're on the selection list, you can hopefully expand it with the Alt and the cursor down key. Under no circumstances should the page or the page content be reloaded with every cursor movement in the selection list. Dynamic changes in forms are generally very problematic, especially with older assistive technology.
We can also test whether our input fields are labeled. The label is a connection of text and the input field so that the visually impaired and blind know what to enter and where. If you double-tap a label such as "Street," the cursor should jump right into it.
In the last form step we enter some data and see if we can send this data with the keyboard. There is probably nothing more annoying than a completed form that cannot be sent. So we enter the appropriate data for the fields and send it off. You should tell the recipient that this is just a test. We do the sending with return as soon as we have reached the relevant button. Please no captchas, but use a decent spam protection.
At this point we should really be talking about client-side validation and fault tolerance, but I think that's too specific. I also refrain from testing an accessible media player here. This is even rarer than an accessible PDF.
Extensibility
All common browsers allow the content of websites to be enlarged. An exception is IE 6, which needs relative sizes, but it's best not to use it anyway. The enlargement is done via the keyboard with CTRL and + or control and mouse wheel.
If we have a classic three-column layout, the page should grow evenly. This means that all content is shifted to the bottom right. The contents should not push into each other even at low magnification. If, for example, the navigation and the content column flow into one another, no one can read it, of course.
Source code
You don't need to be able to read a website's source code to spot potential problems. You can definitely check two things.
On the one hand, it can be checked whether the page is structured correctly.
Small update: The easier way to check the structure: In Firefox, select View -> Website Style - No Style. Here you can see the skeleton of the website and also determine whether the structure of the website is the same with and without the design.
To do this, open the context menu with the right mouse button and select View Source. The browsers work with syntax highlighting, which means the code is highlighted in color. We can ignore anything between angle brackets < and > and just look at the text.
It is important for blind people that the website is structured logically. We expect the header to appear first, then the navigation, the content, the third column, and the footer, in that order. The reason is very simple: since we are going through the website linearly - i.e. based on the source code - it is quite confusing when the content area appears behind the footer, this happens more often than you would think and thanks to CSS it is not a design problem. However, the blind person will probably think that the page has no content.
In the same step, you can also check whether any content can be seen in the source code at all. Often you will see a very short source text where something like frame is written in the code area. Or only a lot of program code is displayed, but no human-readable text. In the first case, the website was designed with frames and is therefore particularly problematic for older assistive technology for blind people. In the latter case, the page is probably generated entirely via JavaScript directly in the browser. The auxiliary software does not cope well with this either.
Conclusion
These simple tests are not a substitute for evaluation by qualified people. They are just a simple means for laypeople to perform simple checks.