Methodology
We consider 11 website accessibility parameters. Each parameter has a value: bad (0) / normal (1) / good (2). Then we sum these values, divide by 22, multiply by 100, and get a number from 0 (everything is bad) to 100 (everything is good). For simplicity, all parameters are weighted equally. This is a basic check, since a full WCAG check involves hundreds of rules, and we don’t have the resources to check them all. But it does give some credit to the site.
Parameters
The site should be visible without horizontal scrolling with a magnification of up to 200%.
The contrast between text and background should be at least 3.1 for large text, and 4.5 for normal text.
These are special links that are shown when the visitor presses TAB after the page has loaded. Usually there is a transition to the main content of the page, but there are other transitions (for example, search, footer, etc.).
When the user navigates the page using the keyboard, the current element should be highlighted. Typically this is a frame around the element.
Any operations with the site can only be done with the keyboard (without a mouse). That is, any elements can be reached with the keyboard. If there are pop-ups, then navigation should be limited to the contents of the window.
All meaningful pictures must contain alternative text. If there is text on the picture, then it is. If this is not a text picture, and there is no description somewhere nearby, then a text description of what is depicted on it. This is also useful for indexing by search engines. For background images, and those that are just for beauty, use empty text.
All form elements must have appropriate labels. Otherwise, the reader will not be able to tell which field the visitor is in.
Links and buttons must contain text. Otherwise, the reader will not be able to tell where the visitor is.
There should only be one H1 heading. It is advisable that the remaining headers be nested correctly, i.e. something like this:
H1
H2
H3
H2
H3
H4
Some visitors use the site’s table of contents, which is built from these headings. This is also useful for indexing.
An accessibility widget is not a native way to ensure site accessibility, so we recommend using it only in cases where other options are not possible.
The fact is that all modern systems already have accessibility support, and the site just needs to not interfere with it. For example, you don’t need to add a text reading function to the site, but you need the system reader to have something to read.
We give 0 points for old menus, 1 for modern ones, and 2 for none.
There must be a declaration page. It should contain contact details of the person responsible for accessibility.