Accessibility Issues That Must Not Be Named

While you absolutely have a point in saying these accessibility issues are present, I can see some VoiceOver-related silliness as well. Let's go down the list:

Your Facebook example is pretty spot on. There is a lot of controls per post, but then again, there is a lot you can do with a post, and a lot of design reasons why they don't stick all of those things into a menu. It appears a heading level 4 precedes every Facebook post, so you can at least quickly cycle between posts that way provided VoiceOver can jump to a specific heading level. I believe it can, I'm not sure if there's a keyboard shortcut assigned to those commands by default, though. This problem is exacerbated by you going vo+right landing on each individual element, rather than just using the down arrow key which in a lot of cases will smooth this out some. Just ...not really on Facebook. Of course not.

The Google Docs example has a good reason: Only VoiceOver and possibly Narrator would be able to actually use the screenreader-provided hotkeys due to most screen readers on Windows and Linux relying on some kind of virtual buffer in order to jump to headings and other such commands. So while VoiceOver would, maybe, and this is a big maybe, possibly be adaptable to be able to use its own web navigation commands, other screen readers would not. Now, another obstacle is that it's not a web page you're navigating, it's essentially a supersmart edit field on a web page, which makes this a lot more technically complicated than it might seem.

The table comment is a good point but, again, not that clear cut. The reason newsletters and other emails often use tables is that they have very little else they can use to lay out their content. On the web, we use CSS (cascading stylesheets) in order to indicate what bit of content is supposed to go where. Most CSS just flat out doesn't work in emails, which is why people tend to use tables a bunch. It's not ideal, and there are absolutely ways around it, but very few developers know these ways, let alone content developers at your local church. For that reason, more often than not I tend to turn table announcements off entirely.

The next point you're describing is interesting; it's a cognitive load issue compounded by the fact a screen reader can only focus on one thing at a time. Visually, an "Account" button is generally very easy and quick to locate because it tends to hang out in a similar spot and tends to look the same. Same goes for screen readers really; the account is usually somewhere in, or just past, the navigation menu, and is usually either labeled with your name, or just "account" or what have you. I would label this a minor annoyance, but then, I'm not you, and this could be very major for you in which case your criticism is very valid.

Your next one is spot on. This is actually one of the more common problems I run into as an accessibility auditor and both issues have to do with what I mentioned before, CSS. Way more often than not, you can make a bit of text visually look like a heading, but not add the actual heading tag. Similarly, you can use a heading to make text look a little bigger without having to write CSS, which is why you often see things like slogans or mission statements as headings. Its an antipattern, it violates all the guidelines and yet people keep doing it.

I'm honestly not sure what you're on about re: the covert text fields. I'm not familiar enough with VoiceOver on the web to diagnose this from afar, but what I am assuming is that the edit fields are either in a modal, in which case see below, or they only show up when you tab into them. The search field on Audible does this, for exaple, which is rather silly, indeed.

Your ghost window point is a fun one: these are referred to as modal dialogs and honestly ...VoiceOver just does not handle these very well in my opinion. On iOS you can usually dodge around it by touching where the modal would be, and that shifts your focus into the window at which point you're all good. The alternative, and I feel this is just a tiny bit easier to do with NVDA than it is with Voiceover, is to find where the dialog appeared and interact with it, in which case you get the controls within the dialog.
THis can actually be a superpower as well; you can often read a blog article without even seeing a cookie banner, but if you actually do need to do something in that dialog, the focus should be redirected to that dialog programmatically. That often doesn't happen which means you need to go hunt for it.

You’ve obviously put a lot of work into quantifying and describing a lot of the issues that plague our web browsing experience and make what should be simple tasks sometimes take all day. It’s getting far worse as time goes on to the point that I really dislike ever using the web directly if it can be avoided. It’s just too frustrating too much of the time. These issues will need to be addressed at some point if a deeper division and digital apartheid isn’t to become our future. Thank you for a great article and I hope others will join in. I’ll have a think about it over the next couple of days and see if I can come up with any more specifics like you have done so well.

I'm blind but tables can be used as a layout tool, visually they, i assume, would make items easier to find, the sighted person just has to skim over two links, for example, to find they want the one on the left, vs skimming up and down through a page.

Perhaps to a sighted person it doesn't matter if it's a table or a list or whatever but yeah, a lot of times it's a visual thing.

It doesn't bother me to much but i'm a windows user and wow! Voiceover just seams to be getting worse on the web, NVDA might have some issues but the browsing experience is fine, at least for me.

I would like to suggest adding another equally important accessibility issue, which I call "narrow-mindedness". This refers to a way of thinking that assumes that only one's own specific difficulties matter and that everyone else should adapt to them. For instance, suppose a shortcut key to jump to the next header interferes with your preferred screen reader functionality. In that case, it may not affect others who do not use the same screen reader. Similarly, not all users may be aware of the specific keypress required to access a text field, and assuming everyone should know it is not reasonable.

The same applies to tables, which have been used for designing more visually appealing GUIs and emails for decades. Some argue that it's up to screen readers to adapt to this behavior. However, when the first iPhone was released, people believed that it could never be accessible to blind users since it had a touchscreen instead of physical buttons. Thankfully, accessibility has improved over the years, allowing blind users to use touchscreen phones instead of relying solely on phones with physical buttons.

Sometimes, it seems like we are still using accessibility software designed for outdated technology like Windows XP, iPhone 3GS, or twenty-year-old Mac computers, despite the advances in technology. Although it's true that some pop-ups may not be read by accessibility software, that is only part of the whole story.
I hope that my observations don't offend anyone, as I believe that it's essential to engage in self-criticism and not rely on miracles, such as expecting the rest of the world to change the way they have been designing websites since the 1990s. With the advent of new technologies, we should be exploring innovative and accessible design approaches that can benefit everyone, including people with disabilities. By acknowledging our limitations and biases, we can create more inclusive digital spaces that promote equal access to information and services.

Paul,

Thank you for putting names to a very good subset of those accessibility traps we clamber over every day. It does seem like so many apps and Web sites suffer from Generalized Obfuscation Syndrome and that so much of our work is just trying to figure out what the site or app creator was really trying to convey or accomplish.

I enjoyed your writing once again.

Take care, and good luck.

You can technically make a WCAG conferment page that uses layout tables, no headings and no landmarks. And that's the problem. WCAG isn't enough to make a web page usable even though it's technically accessible.

At work right now, we're going through the hair-pulling process of creating best practices for our own developers so they don't do stupid things like make divs with no role or put aria-hidden on things they're not supposed to.

Now, my solution for developers who use layout tables, onHover or onClick only events, unlabelled text fields and unlabelled buttons is an iPhone app that detects when the phone is near their groin and gradually gets hotter until the battery explodes.

Just thought you (the original poster who hopefully reads this comment) might want to know. There are billions of actual words in the English language though, so I'm sure you can find one of them that better communicates what you intended rather than coming up with a non-existent word instead.

Because we're using it and it seems to be understood, kind of like "I licked it, so it's mine."
One of my gripes is when websites with, for example, products on various pages, have the products listed in headings on one set of pages, then in some other rabbit hole of pages, list them as alt text to graphics, or just as the text of links. This gets very tedious with a touch screen and rotor on the phone, not quite as bad with a keyboard.

Paul, this is a great article and brings up a lot of important points including those by the commenters. This is not meant to be a criticism and please don't take it personally. I work in the accessibility field and see this mistake all the time.

There is a difference between headers and headings and they are not interchangeable. Web developers make the same mistake when talking about them as well so it is not just about screen reader users.

And thus complexifuscation is still not a word in any factual sense, even if you may wish for it to be so because you happen to use it on one web page of one website. Just like saying, "I liked it, so it's mine" doesn't actually make it yours; if you licked my MacBook Pro, for example, it would not be yours because I would still be the rightful owner of the device no matter what your feelings may dictate. Again, there are billions of other actual words in the English language that do exist, thus we don't need to make up any new ones to get a point across that would best be served by a word everyone already knows (or can easily look up in a dictionary because it is actually real). Let's try to keep language use within the bounds of reality, facts and evidence, shall we?

That reminds me of another gripe. The sites that have inaccessible login features, such as visual-only-personhood challenges. I'll put up with a lot if the service is all right, but that's beyond insulting. And to pile it on deeper, there is one login ordeal that requires screen reader users to register with a third-party.

Interesting discussion you've got going here. Interesting, too, how we Apple users have quite the affinity for details, nuts and bolts as it were. It reminds me of Windows users who used other screen readers, like Window-Eyes.

Anyway. My pet peeve: hidden control state. A div contains a native form widget, skinned to meet conventional standards of beauty, like a combo box, slider, switch, or radio controls that look a lot like the mobile equivalents. The tragedy being, of course, that if you unhide the div and just move the visible elements off-screen, you can use the controls just fine. Keep Safari's Develop menu on hand, so you can disable styles. Re-enable them again once you're done manipulating the controls, of course.

ARIA? I believe that's code for "yeah, you're right, the W3C really is irrelevant as a standard-setting body." Do I really have the energy to Braille in my rant on my iPhone? A more full-scale rant later, perhaps, but the TL;DR is basically that ARIA is a kludge invented to describe features of the web that should already be semantic and have no real need of accessibility enhancement. Also, ipso facto, such enhancement has a long run effect on accessibility generally, because it's completely optional. And, in general, the web as it stands is a hideously engineered house of cards, with the abstractions all the wrong way up. Yes, later, I think.

Lastly, HCaptcha. It is not just that the approach taken is "separate but equal". The other issue is that unlike everyone else, we must let our privacy guard down. Blind? You can have privacy, or gain access. It needs third-party cookies to work, and that's not the Safari default for privacy reasons. Fortunately Turnstyle is changing this, and with iOS 16 or macOS Ventura you can use the ironically-named blinded tokens to prove your reputation. On Chromium-based browsers, install the Privacy Pass extension to magnify your HCaptcha solutions and get more anonymity; use the cookie to get blinded tokens in advance, and they'll generally last long enough to give you privacy.

Mmm, that was far too long to be coherent when written on an iPhone 13 Pro Max just using Braille Screen Input ...

As a web developer who has created applications used by individuals and large corporations alike, I wanted to speak on a few other things I just noticed when re-reading the original post - covert text fields are a myth. The only way to send valid text to a server by way of a form input is through the HTML input element and any attributes it may contain, or I suppose also the textarea element. In fact, custom controls exist more so in the realm of desktop and mobile applications (but especially desktop applications where the breadth of available programming languages and limitless possibilities lets developers create whatever custom controls they wish), but this is not so with web pages; HTML is the defacto markup language of the web for things like forms and other controls, while CSS traditionally handles presentation and JavaScript traditionally handles extended functionality. There would be no reason for a web developer to try and create a custom text field, for example, that does not use the HTML input control, at least not unless they also wish to employ custom JavaScript to handle such a control, and developers of most web applications like myself have far more important things to worry about when building our apps than a custom input control.

Next, sometimes what the original poster calls "dead information" is actually "necessary information" for the simple reason that, as much as we may want it to, not everything can be turned into a link. For example, some pages in an application, like the account settings page, may have such a dynamic URL that it cannot be placed into a link on a different web page without running the risk of being obsolete by the time it is clicked. In other words, part of the URL for a page may be unique to an individual user account, an individual session, or another arbitrary token that can't be included in a link meant for the general public. Be happy the developers put text pointing you in the right direction at all; they don't even have to do that much when a direct link is not possible. Perhaps they could link to at least the login page (in the account example) or something that would get users close, but this is not required either. The web is a mix of programming languages, frameworks, server-side technologies, backend databases, and other things that sometimes mean our desires for how a page must look or behave, or what a developer must include in their application or its help documentation, can not always be honored.

One last thing - I really have to laugh at what you call "table abuse" as it pertains to tables in e-mail messages; anyone who has spent any length of time around web development in any capacity will know that HTML e-mail only allows for a very limited subset of HTML and CSS elements to be used. Thus, using tables is often a necessary consequence of good looking e-mails because the developers want to ensure their messages work across a variety of e-mail applications, some that may implement more available HTML elements than others. Believe me, web developers would rather use modern techniques like CSS3 and etc., but we are stuck with the current restricted subset of allowed elements instead. So this cannot be called "table abuse" in so much as it can more aptly be referred to as, if anything, a "necessary evil."

Sorry to hear about the fall you took at the mall; if only it had been even more damaging, perhaps then it could have restructured your brain so you wouldn't have typed an entire section of your comment that was not related to the discussion at hand. Good thing you saved yourself in the second half of your comment, though I will note that AWS has a command-line interface, a Representational State Transfer (REST) API, and several SDKs for popular programming languages that each let you interact with AWS and its various services without having to use the web interface. Thus, if you're having issues with their web interface, use one of the other interfaces and you might even find your productivity increases. After all, AWS was meant for developers, and developers usually prefer the command line or an API that'll let them complete their work much faster than clicking around a website, and will also allow them to automate or script common tasks as well. The web interface was most likely really an afterthought given how more developer-oriented interfaces are available.

I'm not here to defend google, their commands could indeed be more intuitive. I think, however, this is more of a problem than simply ignorance of screen readers. I'm sure you're familiar with the virtual pc cursor and browse mode in windows land. When you're in an edit field the normal heading navigation for those virtual web views won't work because you'll just end up typing an H. Given that we're on a web site in google docs you can't just do the normal turn on navigation quick keys to move to the next heading with letter H like you can in ms word because you're working in an edit field nested in another web site. So there needs to be some other command you can use while you're editing the dang thing ... and, at least on my windows machine, the normal heading navigation does indeed work when the virtual PC cursor is on. I just can't use those normal screen reader commands while I'm actually working with the document. It will just type h or t or whatever and that's no good. I'm not sure how it works in MAC but I can sort of see google's logic here.

I want to be clear that in windows land with Jaws or NVDA you can indeed use the normal screen reader commands to navigate as long as you switch out of your editing mode into browse mode or virtual PC cursor, then go back into focus mode or forms mode to edit. I do it all the time. But people really struggle with that concept often so google made another way which, yeah, I find more confusing. But nobody’s stopping me from switching into the virtual view, using the regular screen reader commands then going back into forms or focus mode. Again I’m not sure how that works on MAC but let’s be accurate here. I do indeed see the screen reader agnosia problem lots of places, especially in programs that aren’t web sites, but at least in windows land and obviously with chromevox you can just use your normal navigation commands if you know what you’re doing.