Barriers to Internet use

Modal Frames

An increasingly common practice is interaction using modal dialogs. In this method, content (typically forms) is opened not as a pop-up menu in a new browser window, but in a layer that hides the underlying content. Be it choosing a pizza topping or entering payment information: Often this interaction model is found at critical points. All the more annoying when it becomes a barrier. Typically, the screen reader does not interact with the overlay menu at all. In many cases, there is even no indication that one has appeared. So you still move on the underlying page without suspecting that something else is actually demanding your attention. The following video gives an impression:

How to do it better?

Basically, you have to make sure that the screen reader's focus is set on the new dialog. As in this example for a successful dialog.

Captchas

We probably all know and hate them: Captchas - or the proof that you are a human being, which you pay for with strain and lifetime. For blind users, it is obvious to offer an audio form instead of pictures with text distorted to the point of illegibility. However, as logical as this consideration is, it is not suitable for practical use. Several serious problems arise:

1. Get captcha and find text field

In most cases, you have to activate a link that retrieves the captcha. This is then played immediately.

The problem with this is that I then have to navigate with the screen reader to the text field intended for the captcha code. So suddenly I have two different pieces of overlapping spoken content.

Here is a simple example of this:

2. Captcha retrieval

The example we have just seen is a very simple one. Normally, a new tab opens, so there is the additional difficulty of quickly finding the right tab to search for the text field.

3. Understand audio captcha

As if that wasn't hard enough, audio captchas have become absolutely incomprehensible for the most part in recent years, as evidenced by the next two examples:

If you take it with humor, you can of course say: Fair is fair - why should blind users be better off than sighted users, who can hardly decipher the images anymore.

How is it better?

A screen reader user navigates no differently than a bot. Google's recaptcha is therefore not a solution in most cases. A captcha that allows simple math problems to be solved is more interesting.

The best option, which is also the only justifiable one in terms of service, is for companies to stop making their spam problem the problem of their potential customers.

Copy/Paste

It gets really interesting when texts are written in some formats that then lead to invisible problems when copied into the WYSIWYG editor, making the content at least difficult to understand for screen reader users.

Yo-u wo-uld-n't wan-t to r-e-ad som-e-thi-ng so h-ack-y, wo-uld y-ou?

What reads strangely sounds like this through the screen reader:

Where does that come from?

On the one hand, as mentioned above, this happens when copying from a word processing program (hyphens of the automatic hyphenation are copied as well), on the other hand, the conditional hyphen "&shy" is the guilty element for this.

Basically it can be said that hyphenation, if you absolutely want to use it, belongs in CSS and not in HTML. Then you can hyphenate as often as you like without making it unreadable for blind people.

By the way, it also reads on the Braille display exactly with such hyphens as in the above example.

Conclusion

Apart from the audio captchas, everything presented here can be improved relatively easily if the attention for these pitfalls is present. The captchas, on the other hand, are practically lived inclusion and show very impressively that there are techniques that are similarly annoying for all users. So in the end, we're all in the same boat. Let's make sure that it's a relaxed stay!