Whether on my iPhone or my Mac, I encounter accessibility issues pretty much daily.
Yes, much of it is the usual---mouse-centric controls, unlabeled buttons, and images without ALT text---commonplace issues that have been highlighted for years. I don’t want to minimize these issues, but I view them as minor. They are well-known. They have names. We can talk about them in discussions with developers. Free utilities are readily available to help find them.
It’s the accessibility issues without names that keep me up at night. Problems that we never discuss because the English language has no words for them. They are the Lord Voldemort of accessibility issues. They are Issues That Must Not Be Named.
Naming something is a powerful tool. It shines the light of critical observation on a thing that we knew was there all along but hovered just beyond conscious thought. With Global Accessibility Day (GAAD) coming up in two months, I thought I should describe and name these unmentionable accessibility problems.
Once christened with names, these bugs seem much less intimidating. Fingers crossed, maybe W3C will add them to a future WCAG revision.
Complexifuscation
Complexifuscation describes websites or applications that would normally be considered accessible if they weren’t so astonishingly complicated and cluttered.
Here’s an example. Suppose I want to read newsfeed posts at the Facebook website. I open the list of headings with VO+U and arrow down to Newsfeed Posts. So far, so good. But my only recourse for reading the post text is to use VO+Right Arrow, and here’s what I encounter.
- BLIND AUDIOBOOK CLUB article
- BLIND AUDIOBOOK CLUB link
- Beth Omansky link (This is actually useful, as it tells me who wrote the post. Hi Beth!)
- 35m link
- Shared with Members of BLIND AUDIOBOOK CLUB group
- Image
- end of Shared with Members of BLIND AUDIOBOOK CLUB group
- Actions for this post menu pop up button
- hide post link
Finally, the next VO+Right takes me to the post text. I’d mention all the other controls that seem to be needlessly present, but these blogs do have word count limits.
I’m not trying to pick on Facebook. Many discussion forums suffer from over-complexity and clutter. Anything that uses phpBB is particularly Complexifuscated.
Complexifuscation exhausts vision-impaired users, period. It is the most significant accessibility issue that never gets discussed.
Screen Reader Agnosia
Screen Reader Agnosia is the presence of custom accessibility functionality that replicates features already available in most screen readers. It is strong evidence that the software developer is unaware of how screen reader software works.
As an example, Google Docs provides the keyboard shortcut Control+Command+N, Control+Command+H to jump to the next heading. Screen readers already provide heading navigation shortcuts (VO+Command+H). If Google were more familiar with screen reader technology, they would’ve implemented support for existing screen reader shortcuts. Instead, they created yet another shortcut for us to learn, and one that is unique to their web software.
Screen Reader Agnosia doesn’t make their website accessible. It burdens us with something else to memorize.
Table Abuse
I’ve selected the name Table Abuse to describe the use of tables for anything other than the display of tabular information.
I often encounter table abuse while reading email newsletters. As I navigate through the newsletter, VoiceOver will announce something like, “table, 1 column, 2 rows.” But as I continue to navigate, I encounter an image, for example, and maybe a line of text that sounds like a section heading. I’m surprised when VoiceOver announces, “end of table,” because I didn’t hear VoiceOver read any tabular data. I navigate back into the table, hoping to find the information that I somehow missed.
When screen readers announce tables, screen reader users expect to find tabular data. The absence of that data impedes comprehensibility.
Dead Information
Dead Information is any text that directs you to take some action but requires you to leave that text in order to execute the action.
For example, imagine browsing a website and encountering text that says, “Click your account to change settings.” And further imagine that’s exactly what you’d like to do. The only problem is that the word, Account, is not a link. So you can’t click it. Instead, you’re forced to search the website, hoping to find a link or button labeled Account.
I’m certain developers included the text in the mistaken belief that they were being helpful and informative. But if they really wanted to help, they would’ve included the necessary link in the instruction. Instead, they gave us Dead Information.
Palette Glare
Palette Glare is the presence of both dark-on-light and light-on-dark color schemes in the same page or window.
Low vision users commonly invert colors to avoid the glare of light backgrounds. If a window uses both dark-on-light and light-on-dark color palettes, there is no invert colors setting that will avoid such glare.
The fact that several applications fail to honor dark mode is yet another example of Palette Glare.
Heading Anemia
Heading Anemia is the absence of heading elements above relevant content. Finding an example is left as an exercise for the reader . It’s not a hard exercise. Websites commonly fail to use headings.
The only thing worse than Heading Anemia is Heading Cancer, in which the overuse of headings dilutes the ability to use them as navigational aids.
Covert Text Fields
Covert Text Fields accept text like standard text fields, but they aren’t standard text fields.
You’ve most likely encountered a Covert Text Field while attempting to sign in to a website. After selecting the Sign In” button, you open the VoiceOver list of form controls with VO+U, but the text fields for username and password are nowhere to be found.
Sigh. When developers use custom controls, accessibility is often the first casualty.
Ghost Windows
Ghost Windows pop up like real windows, but VoiceOver focus passes right through their phantasmal forms.
Here’s an example. You click a button or link to take some action, but nothing seems to happen. Your sighted friend looks over your shoulder and tells you that a dialog has popped up. Unfortunately, there’s no way to access the dialog content with VoiceOver. Your sighted friend tells you the VoiceOver highlight rectangle is moving right through the Ghost Window. It’s scary.
Ghost Windows have been infecting modern websites like an unchecked plague. I’ve seen them at CoinBase, NaNoWriMo, and dozens of other websites.
Conclusion
Accessibility Issues That Must Not Be Named. They are the Lord Voldemort of issues. Though they have been nameless until now, they are nonetheless real accessibility issues that impede usability of websites and applications. It’s high time that W3C include these issues in their WCAG guidelines.
I’ve wanted to write this blog for years, but have put it off because it’s so difficult to find the words. I’m sure it’s not a complete list. How about you? Care to describe an accessibility issue that never gets discussed? Please do so in the comments, and extra points if you come up with an appropriate name.
Comments
Some nuancing
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.
One of the best additions to this site.
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.
the jank
Using tables for layout is one that really grinds my gears.
Tables. Are. Not. A. Layout. Item. STOP THAT. Go learn CSS and semantic markup like you were supposed to. No, accessibee won't fix your garbage HTML. Semantic markup where you can. ARIA where you can't.
A lot of these problems boil down to just straight up bad UX. In other words, jank. Take a look around, you'll find jank everywhere, and I really mean /everywhere/. In fact, the larger and more complex and more money that was poured into an interface, the more jank you'll usually find. New all. The hamburger menu. "Click the button below"... except it's a link. Hcaptcha. Amazon Web Services. Salesforce. Sibelius. Powerpoint. The iCloud website. Nexus Mods. Every government office ever. Convention registration websites. I find that, when screen reader users have a negative experience, a lot of sighted users also have a negative experience. It's yet another argument of why a11y should be baked in from the start. Everybody wins from the backend devs who no longer have to deal with spaghetti code and the <div> masquerading as a button to the end users who can now actually use their password managers and auto-fill tools to the marketing experts who no longer have to turn nameless functions into a feature they can sell. Even the documentation writers benefit because they no longer have to waste time writing separate procedures for screen reader users.
I think Screen Reader Agnosia is a product of the modern web. Say it with me, the world is a web app. Visual Basic and C++? Hahahahaha. Get outta here. Just run everything in Electron! Everyone has like a gigillion gigabytes of RAM anyways! Unfortunately, your web browser has its own bank of commands, and developers have to squeeze in more of them somehow. I bet they'd make good money from selling a version of Twister specifically for your fingers. Screen readers can find the next heading, but that doesn't work so well when your web app requires you to be in focus mode because most of it is a blank text field a la Google Docs. It's a crummy solution to a problem that exists because people are obsessed with making everything visual and because it's built on top of a platform which is built on top of a platform which is built on top of a platform which is built on top of a tower of duct tape. I am not a full stack developer, but I've dabbled in enough components from high-level stuff down to C and Rust to know that it's jank all the way down.
As for Facebook, I blame the evil machinations of php which is an evil language and also zuck.
tables.
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.
agree, but...
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.
Thank you, sir!
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.
@Brad @Alan
I partly agree with this. @Brad visual layout can be laid out a combination of html tags and styling rules that make tables unnecessary in the majority of cases. This is where semantic markup comes into play. You can use sections and combine them with divs and styling rules to create columns or a sidebar or just about anything. Visually, everything is pretty and sighted users can find links quickly. Semantically, blind users and keyboard users can make sense of a page without having to do many complex keystrokes or excessive tabbing to find what they're looking for. Tables give semantic meaning because they are specifically for tabular data: a list of emails with subject and sender info alongside a body preview and a few buttons, a list of users in a database, the results of a survey, a set of download links which display the version number and a checksum for each link. I mentioned ARIA because it's one of the languages that many developers use as a crutch. You could probably use ARIA on a table to make a screen reader play nice and not have somebody navigate a table with 1 column and 50 rows, but it's just easier to use a table for its intended purpose and arrange your text and images and whatnot with industry-standard best practices like those laid out in WCAG 2.1. It's less work for developers. It's fewer headaches for users. It's less time for auditors. Everybody wins. ARIA has its place for parts of the structure that don't have an inherent semantic meaning like a combo box, but using it on something that does have that meaning like a table or a footer complicates everything and makes a worse experience overall.
I get riled up about this sort of thing, not because I'm a crotchety old curmudgeon who can't let go of Windows XP and the command prompt and walked uphill to school both ways etc, but because this is important for building a better user experience that's more accessible to everyone. It's the same argument for any commonly-adopted industry standard: encryption, text encoding, media playback, spacing between buttons. Imagine if you had to install an entirely new character set every time you visited a new website because their system admin decided to interpret the arrangement of ones and zeroes slightly differently. This was often the reality before standards like ASCII and Unicode came about.
@Alan your example of the iphone is a unique case where standards don't exist because the tech is so much newer. Those standards do exist now because a few companies pushed the boundaries of what people thought was possible. Nowadays, touchscreen accessibility is commonplace and precedents are set on how to do it because of companies like Apple. It was a rough while before it got refined and spread. Now, you can look up accessible interface design for touchscreens: how big should buttons be? How far apart should they be? How should they be labeled? All that said, it's still relying on HTML and C# and SSL and lots of other established technologies that have been modified and adapted to become more than the sum of their parts and make something really cool that hasn't been done before. All new technologies have their growing pains. Disabled people, unfortunately, get sucked up into the mix of frustrations and barriers that come with it.
I'll leave you with one last bit. the largest base of non-sighted web users are smart speakers. Yet another argument for following accessibility best practices and why everyone wins when the world is accessible.
Enjoying the discussion
Thanks for all the comments so far, everyone. I've achieved one of this blog's goals - getting people to talk about accessibility issues not present in the WCAG standard. I'm enjoying the discussion.
Let me step forward to defend Dead Information as an issue. It might not be an accessibility issue per se, but it is a poor design choice, and it disproportionately impacts vision-impaired users. There's nothing worse than filling out a form, navigating to the Submit button, and finding it grayed out. If you're lucky, you stumble across text that tells you, "You must complete all required fields." That's Dead Information. How about a link to allow me to jump immediately to the field in question? And I know from living with my sighted spouse that this is a problem for sighted users too. Get rid of Dead Information, provide an action mechanism instead, and everyone benefits - sighted or vision impaired.
WCAG Ain't Enough
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.
@Kevin Shaw That's a big oof…
@Kevin Shaw That's a big oof. I never even considered that scenario. A dev who builds websites like that deserves to have their servers melt. I commend you for pulling that hair to build good UX.
One of the best wordings I've seen for interface design comes from Salesforce Trailhead. When you give an element a meaning in your interface, you are making a promise to your users. Making it function different to expectation is breaking that promise. This isn't verbatim, but it's close enough. Lots of websites break promises... including Salesforce!
On a related note, I encountered dead information just yesterday. Dropbox's recent major change to their Mac app broke a bunch of functionality in Logic and Final Cut related to opening projects and importing media from certain locations. I sent a support ticket. Only problem is I sent several dozen because the "send" button gave no feedback whatsoever. I found dead info just below informing me that the ticket had been submitted. Bonus points is that, when I closed the window, Safari popped up a dialogue warning me that there was unsubmitted information and that I would lose it if I clicked close. I could rant about Dropbox's bad UX for an hour. I will not. I think there's a lot of opportunity in UX and building something that people actually want to use. Again, taking accessibility into account often builds an interface that's better for everyone because hey wouldn't ya know it, industry best practices are good for something! Also yes I agree WCAG isn't enough. It's a baseline to be combined with many other good practices and standards to build good interfaces.
To those who have a little time to kill, I suggest watching some of Tantacrul's videos on YouTube. He makes music and heads the Audacity and Musescore projects and talks a lot about design, both from an aesthetic and functional perspective. He's also funny and uses memes and stuff.
Software and haircuts
In this blog, I tried to name some accessibility issues that I thought should be part of standard accessibility guidelines, whether WCAG or some other. But clearly, either such guidelines will never go far enough, or developers will just ignore them
It reminds me that, some decades back, there was an effort to have software developers be licensed. And with a web search, I managed to turn up some contemporary information on the topic, so it's not a completely dead idea. It makes sense. If my doctor, accountant, taxi cab driver, and even my barber need to be licensed, then why do we let kids who can't even spell the word "accessibility' code our user interfaces? If software development were a profession, developers would face consequences for code that did not comply with best practices and accepted standards. This might be the only way for accessibility to ever achieve the respect it requires.
"Complexifuscation" is not a word
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.
"Complexifuscation is a word
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.
Header Anemia
@OldBear, I used to by computer equipment at a website called NewEgg.com, but stopped because the search results had no headers or any other efficient mechanism for navigation.
Headings vs. Headers
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.
Facts don't care about your feelings
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?
@PaulMartz
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.
Good catch, re: headers
Thanks @Mark. I do know the difference, and can only plea old-man-brain-cramp. I have corrected the article text. Headings is the correct word.
CAPTCHA
Hi @OldBear. I think inaccessible personhood tests should already be covered by WCAG.
I was very disappointed with my purchase of an Arris router last year. They had incorporated visual-only CAPTCHA tests into the router administration page, and forced me to repeatedly pass the challenge, even with my laptop wired to the router. I just didn't get it.
The CAPTCHA that requires you to register is hCAPTCHA. Once you register, you get an accessibility cookie that allows you to pass the CAPTCHA challenge. Unfortunately, the cookie expires after 24 hours, which means you constantly have to return to their website and download a new cookie. It's an interesting idea, but a poor implementation.
@neosonic2
I googled for velcro straps to tie down my jetski. I was looking for something with good dependability but the only stuff I found was worthy of being thrown in a dumpster. Anyway, I stopped by the mall and rode the escalator up and bought some granola and q-tips. I then took a fall and had to put on a band-aid. Thank goodness I didn't need a steri-strip. Anyway, I washed my hands in the sink and also swished my mouth to get rid of my halitosis from the popsicle I'd had a few hours ago for good measure. Later on, I booted up my PC and made a song with autotune. While it was exporting, I decided to pull some tupperware out of the fridge and use my crock pot to cook dinner. I took a swig from my thermos and kicked back while watching a video of some friends playing frisbee. My hands got a little fidgety, so I started playing with some bubble wrap left over from a recent delivery. I then got a text from a friend whose kids had stuffed the jacuzzi with play-dough. He was thinking of buying a trampoline for his own use as well.
Anyway, to keep this on topic, yeah complexifuscation really is quite the conundrum. I experience it with Amazon Web Services. It's a terribly complex interface that I'm convinced is just to make your boss think you're being productive. Unfortunately, it makes my job a lot harder.
Hidden State, ARIA Really is Evil, and So is HCaptcha
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 ...
Myths in this article from a web developer's perspective
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."
@Jenna Pepper
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.
Re: Screen Reader agnosia
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.
Let's think about accessibility for a second
Thank you for the comments on both Table Abuse and Screen Reader Agnosia, issues that I feel passionately about. I understand the assertion that these issues exist because developers had no choice. They had to use a table to center text because email supports no other option. Google Docs couldn't support basic screen reader functionality because, well, it's still not clear. Maybe they felt they had no other option, too.
But I am a blind user, and all I know is that tables with no tabular data make me feel like I must have navigated past something important. Or I opened a text document in Google Docs and couldn't navigate it because the keyboard shortcuts I use with my screen reader everyday don't work.
It's important to remember that no one forced email newsletter users to center their text. It was a conscious decision they made with no regard for how it might distract screen reader users. And it was a purely cosmetic decision. It was unnecessary.
As for Google Docs, do we really think they had no choice but to develop a palette of incomprehensible and awkward keyboard shortcuts? Isn't it much more likely that, if they had given priority to screen reader support at the inception of their project, they could've designed an application that presented a far superior experience for screen reader users? Again, no one forced Google to create an inaccessible app. They made a decision, conscious or otherwise, to create something that requires blind users to learn an entirely new clumsy interface. I can think of no worse experience than spending time mastering a screen reader, only to open an app that utterly fails to support anything of what you just learned.
Agree or disagree, I appreciate the comments and discussion. At least we have names for these issues now. At least we can discuss and debate.
Agreed on Google Docs
It really is a good example of screen reader agnosia. At the end of the day, I'm aware of why they did it like that; it's a web interface built inside of a browser which makes keystrokes really complicated.
Still, it makes me rue the day somebody suggests we collaborate in google docs. Great. Let me just bring my finger warm-up kit and prepare to tie them into knots. It's complex and frustrating and really feels like they were chosen by some engineer who was told to prevent an ADA lawsuit. Working within the limitations of your codebase doesn't mean you automatically build a good UX. People like @neosonic2 make a fair point in regards to tables being used in emails. Frankly I'd rather devs stick to headings and links in emails. I hate tables in emails so much. Again, just because it's the best one doesn't mean it's good. In regards to custom controls, I've seen plenty of ARIA bodges and Javascript japes. Those not-button buttons and those non-text fields that will actually function as text fields. I often see it on pages that are complexifuscated and use some fancy AngularJS SPA solution thing since their devs haven't restructured their brains to think from the user's point of view. In regards to my previous imposition, I do apologize. I thought you had realized I was using words which were made up but have since entered regular lexicon. I now see that it sailed over your head.
Covert text fields
I have seen web pages that have a text field for user name, a text field for password, and a submit button. But when I press VO+U to list the form controls, only the submit button is present. I have seen entire forms consisting of multiple text fields. Some show up on the Form Controls menu, some don't, and often it's the ones related to entering credit card information.
Calendar Complexifuscation
As another example of Complexifuscation, I submit the popular calendar widget that does not let you enter a text date, but instead forces you to navigate through buttons for each day. After you select the desired day, how you move to the first non-calendar element is anyone's guess, which means you usually end up pressing VO+Right past every day of the month. Worse, this widget often displays two months.
This should be easy for an automated accessibility checker to identify and flag.
Google docs and screen reader redundancy
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.
Covert text field example
Here's a concrete example of a covert text field.
Sign out of AppleVis. Then select the Log In link. Next, press VO+U and arrow over to the list of Form Controls. As you arrow down the menu, notice that the username and password fields aren't listed. You can navigate to them, and you can type into them, but they aren't normal text fields that VoiceOver would recognize as form controls.