Annoying website features I face as a blind person
bighack.org
bighack.org
"There are a number of different issues at play in universities at the moment. Stock photograph of students talking at a table. We spoke to the dean of the faculty of social sciences..."
You can see that this is pointless alt text. So the default should be no alt text unless there's some content in the image that is important for the context of the article.
I'm even dubious that photos that show something described in the article should have alt text, and I'd be interested to hear from blind and partially-sighted users what they think. For example:
"The dam burst on Saturday, inundating the local town. Photo of burst dam with rubble and uprooted trees at the side. The mayor said that they were lucky nobody was injured..."
Presumably if what the dam looked like after it burst was described in the article, that image shouldn't have alt text?
How are you to know if this image is purely decorational or if the author just didn't include any alt text, like happens so often?
Also, don't think of the alt text as part of the surrounding text. Think of it as many browsers would display it, a box with a broken image icon with the alt text besides it. Would you not wonder what would have been displayed there if the image would work?
And do images that are just for decoration really need to be images? Can they not be for example background images in other elements? Like styling an hr element for a visual divider instead of using just a divider image?
But in any case, provide some alt text! If it just says "divider", "logo" or "decoration", that is still better than nothing for someone who can't see it at all.
https://www.w3.org/WAI/tutorials/images/decorative/
https://web.dev/image-alt/#how-to-add-alternative-text-to-im...
https://yoast.com/image-seo-alt-tag-and-title-tag-optimizati...
As far as I understand it, screen readers should skip over the image with an empty alt attribute because it's like a page in a document saying "page deliberately left blank". Unlike no alt attribute in which no intention can be inferred and which screen readers do read (as far as I know they read the URL), an empty alt attribute is deliberately saying "ignore this image". Not being blind or partially-sighted I'm not sure whether this is the case in all screen readers, or whether theory is different than practice.
I don't use one myself and have most of my knowledge from friends that do, but this info is obviously outdated.
Screen readers have skipped over empty alt attributes for decades. I'm not certain they ever behaved differently, but if there were a time when empty alt attributes caused problems, it was back in the 90s. Best practice for purely decorative images has been to use empty alt attributes for 20+ years.
Maybe my memory is off but I think up until the middle of the first decade of this century empty alt text was not good for screen readers, although maybe that was just because you always have to take into account older screen readers still in use.
https://www.w3.org/TR/WD-html40-970708/struct/includes.html#...
This is a generalisation and one that many screen reader users wouldn't agree with. People who can only read through audio or braille are already facing certain disadvantages, such as not being able to quickly scan a piece of content in the same way visual readers can. Polluting the content with meaningless alternative text makes for an overly verbose user experience.
> Empty alt text means no image description. Think about that. You are blind. Your Screen reader tells you "image", nothing more.
This is factually incorrect. Using an empty string as the alt attribute on an image is the correct way to mark an image as decorative, and as such a screen reader user will never be informed about its presence. If the alt attribute is omitted entirely, that's when screen readers try to guess by announcing the filename and/or URL (or on iOS, actually trying to perform object recognition on its contents).
I guess you can then use alt="" for "decorational" images and practically hide them from screen readers? It still seems odd to me though to even have these kind of images.
Of course a stock image in an article is not really important and may not add much value, but someone thought including it did add some at least. It just seems weird then to say that screen reader users should never even be made aware that it is there.
Obviously from all the comments, this seems to be what people do. Still, it seems somehow wrong to me. If the image sets tone, should we not try to convey that? If it really serves no purpose, should we not just leave it out at all?
Not sure if anybody has mentioned this, but a super common case is that stock and other images (photos especially) require attribution. Working in the digital accessibility space, I see a huge number of examples of an image being marked as decorative (or worse, being implemented as a background image in the CSS) with an inline credit line. So as a screen reader user, I'm reading an article and keep spotting these notices all over the place, with no hint of what they accompany. In those cases, the image must have a description, even if it is thought that it doesn't add value.
Haha! Someone of roughly my own vintage I see...
I get what you're saying, but perhaps if you think about it in terms of sensory modalities it might help. There are images which convey a feeling purely through its aesthetic that are ruined to the point of uselessness by plain description in written language, a bit like having to explain a joke: "You see, the expectation is that the chicken crossing the road is going to be for a funny reason, like a pun, or something, but having set up that expectation the fact that you've subverted the expectation makes it funny."
Another good example might be the story in this This American Life episode of the guy who sees a colour that is indescribable: https://www.thisamericanlife.org/577/something-only-i-can-se...
Better not to interrupt the reading flow just to let someone know there's something there, the purpose of which you can't really describe in any meaningful way.
Spamming a page with redundant visual imagery that's easy to take in at a glance is fine. But its terrible to screen read, because reading is much more expensive than glancing. For the alt text, it's important to only give valuable non-redundant information.
I feel like this is something where AI can actually shine: generating descriptions of images and video for blind people.
Best of all it's already a solved problem (and others have thought about it already): https://www.blog.google/outreach-initiatives/accessibility/g...
The next step is using AI to describe (important) changes to pages. Think of a chat on a website with new messages appearing. A voice saying: "Alice writes 'hello'" goes a long way. Thinking of it there really ought to be a way for JavaScript to interact with screen readers, allowing developers to give changes performed by JS something like an alt text.
The final step would be using AI to make interacting with sites easier. Finding the right button/element to click/focus can be really annoying with a screen reader. If you could just tell the AI "fill the form with X and Y and click submit", or "go to the next page", and possibly having that work even if what you're looking is buried in some context menu, pretty much any non-accessible page becomes accessible.
That's exactly what you don't want in the majority of cases. The alt attribute is for an alternative to the image, not a description of the image. For decorative images, the alternative is the empty string, no matter what the image contains. "Laughing group of people" might be a correct description of a stock image, but completely wrong as alt text. For, e.g. a red arrow pointing out a required field, the alternative is "Required", not "Red arrow pointing right".
If you have Instagram, scroll through the alt text on the images some time. You'll see descriptions like "May contain: Person standing outside". That may be an accurate description of the picture, but it may be a poor substitute for what a sighted person sees -- someone showing off their new sweater, or posing in front of an interesting wall, or an aesthetic splash of colours. Of course, maybe someone who is fully blind doesn't care too much about a splash of colours, but the point is that describing an image is more than just about identifying the individual objects visible in the image. Because when we see a picture of an adorable puppy, we get more out of that image than just "dog sitting on floor". As of now, human-generated alt text is still the best solution in most cases, even if we are definitely making progress with AI. It's hard enough for humans to describe the aesthetics of an image, let alone a machine.
Decorational images aren't important, so use empty alt texts or aria hide them.
Most images should have short, to the point descriptions, containing the information you need to fully enjoy a given article. When writing a good alt description, think about why the image is there and why does it matter, not only about what it shows.
There could be two articles with the same image, but completely different alt descriptions. If your article is talking about how pretty graphs produced by a given tool are, describe what kinds of data the graphs contain and how they look like. For example, "A screen with three graphs, showing a company's stock prices across the last month, year and decade. There are points for the highest and lowest values marked on each graph. There are also average prices displayed". It doesn't matter what company it is, or what the actual values are. If your article talks about how tech companies did during the coronavirus pandemic, that same image would be described like "the stock price of x was $100 on march 20th, fell to $5 on march 21st, then slowly started rising, ending back at $95 on june 3rd". Same image, completely different information highlighted.
Sometimes you need very detailed and complete alt descriptions, particularly when you're describing diagrams showing complex relationships, function graphs and so on.No, "screenshot" is definitely not a good alt when you're trying to show what kind of output a given command is expected to produce. Yes, you should painstakingly retype the text (assuming you can't copypaste for some reason), or at least put it through OCR.
No. The alt text is fine. It's the image that is pointless.
The problem is admittedly worse for the blind, but bothering to varied extent also some of the non-blind.
Divider lines etc done as images should have an empty alt-text to be skipped.
Whether an image is decorative or not is a complex question that probably hinges on a lot of modernist ideology about the role of ornament[1].
A more functional approach is ask why the image is there. If it’s setting a mood, describe the image with words that evoke that mood.
In my case, the image was an illustration that I’d written off as not interesting to a blind person. But in putting forth the effort to “read” the image I realized it depicted our target demographic using our product in a fantasy setting, which is much more fun to describe than it appeared at first glance.
In your example, the "rubble and uprooted trees" aren't mentioned in the surrounding text. So this image description, while a bit short and vague, does add something.
I'd argue that if the image is useless to the narrative, it shouldn't be included at all, blind users or not. But in your example it does seem related to the narrative, and just as we can say that non-verbal cues are important to spoken communication, non-written cues are important to written communication.
This doesn't always do what you think it does. The presentation role is for negating any accessible role implied by the use of a particular HTML element, not for hiding it entirely. For example, you've used an unordered list for appearance/styling, but it only contains one child item. In those circumstances, a list of one thing is semantically meaningless and role="presentation" on the ul is completely appropriate.
The fact that applying the presentation to an img removes it from the page for screen reader users shouldn't be relied upon.
By comparison, alt="" is much less direct and obvious. I consider it an unfortunate historical quirk that it is not the same as a nonexistent alt attribute.
For decorative images I recommend using presentation role to make the intention clear.
Edit: Perhaps a news story where the victim of a crime is in the foreground of an old photo and the person who committed the crime is in the background. But then that would be referenced in the text of the story, and the alt text would mention that reference.
Setting the alt attribute to an empty string already accomplishes this task. If you find there are cases where it shouldn't, as well as reporting it as a bug to the appropriate browser and/or screen reader vendor, you can use aria-hidden="true" on the img. This is useful e.g. for inline SVGs which don't have an alt attribute.
The primary categories of images that exist are:
• Decorative or ornamental imagery. Part of art direction; typically implemented with CSS (commonly background images) rather than <img> these days.
• Stock imagery. Part of art direction. An annoying waste of time, space and bandwidth that is unfortunately valuable because of human psychology.
• Meaningful figures: photos, diagrams and other images that are actually related to the content.
Art direction <img> tags should always have an empty alt attribute, even stock imagery: because it’s not adding anything to the content. (I hear someone crying, “but I put that stock image there for a reason!” Sure, you put it there to manipulate a particular facet of human psychology, but it’s purely a visual phenomenon, and it doesn’t transfer to other media at all. In fact, rendered to speech it’ll have the opposite effect, so drop it like a hot potato. There are equivalent phenomena for other senses, e.g. there’s a reason audiobooks, podcasts, &c. add music; but you can’t do that in this place.)
What remains, then, is the meaningful figures; and for that, I hold that images should basically always be described in the visible text anyway, typically as a <figure> with a <figcaption>. And if you have a <figcaption> describing the image sufficiently, I see no cause for any image tag to have anything but empty alt text, because you shouldn’t be writing the same thing again, and there’s no other useful value. Some decry this, and insist figcaption and alt serve different purposes and you should have both, e.g. https://www.scottohara.me/blog/2019/01/21/how-do-you-figure...., part of an article which another decent resource https://webaim.org/techniques/alttext/#figure cites, but I disagree with the argument and its conclusions—especially its “if you empty the alt then the figcaption is not describing anything”, because the figcaption was never describing the image in the first place, but rather the figure, which is still there. Hiding the image in this way because it has been fully described is thus perfectly reasonable.
(Related: avatar images that are paired with the user name in text should have empty alt text. Otherwise you get the name twice in a row. In this case, the image is effectively ornamental, just like icons on buttons that also have labels are ornamental. I receive emails from multiple systems and interact with multiple web apps that commit this sin. It’s annoying, especially when they style things in such a way that the visual presentation of alt text when the image is not loaded is broken anyway.)
So the main case that people might think is left is diagrams where a figcaption would say “the results of such-and-such a benchmark” or similar. But even then the alt text should quite probably be empty: remember also that alt text shouldn’t be too long; the picture may be worth a thousand words, but alt text should not be even a tenth of that length, so you probably shouldn’t list all the values of a bar chart in alt text. Rather, any details that matter, draw attention to them in the caption or the prose surrounding the image! Also most diagrams would be better done as SVG, and if you do that you have much finer control over accessibility presentation than alt text, as well. Though you still have to be careful about pushing too much information to the screen reader.
To be clear, I’m not saying that everyone should take their documents and document.querySelectorAll('img').forEach(e => e.alt = ''), but rather that they should strongly consider designing their documents and massaging their content to the point where that is reasonable, with writing good captions and the likes.
I disagree as a screen reader user. To be clear, I completely support your assertions around describing complex imagery, e.g. the alt text is a completely inappropriate place to describe a graph, chart, etc. But a figcaption with no accompanying figure content is semantically wrong. If you have a figure with a textual description or semantic representation of the data displayed in an image, e.g. a table behind a disclosure button, then fine: the figure body is meaningful, as is the caption. But if I'm testing a site and find cases of figures where the only screen-reader-accessible element is the figcaption, that is an antipattern that I will insist be addressed.
What would you do? For a concrete case, let’s say you have a bar chart in a <figure> with the figcaption “Figure 3: results of Benchmark Q, showing X to be 40% faster than Y.” What alt attribute would you give the <img src=benchmark-results.svg>?
Let's imagine a more realistic bar chart with the results of benchmark Q, showing the speed difference of X and Y in four different [resolutions/tasks/memory limits/processors/whatever], so 4x2 bars. Should the advantage of X over Y and all the other patterns visible in the chart be described in the figtext? IMHO not. In such a case, a reasonable alternative for that content would be not a sentence but a data table, providing all the information but leaving the interpretation up to the reader - just as for the visual chart.
Completely agree with this (and your other comments re: interpretation). In the real world, it's rare for content and data to be as simplistic as the example described here, and presenting it in an inclusive fashion which allows all users to make their own conclusions is the key.
In this case, the bar chart most likely should be accompanied by an accessible textual alternative. For example, a link to a textual version/download of the results, a disclosure button you can hit to view a textual description, a table, whatever. If that is included, the img itself can be marked decorative, because the figure contains an accessible body element as well as the caption. For me, that would most likely be enough to pass my semantic and accessibility requirements.
On the other hand, if you're not going to provide that or feel that the caption already sufficiently describes the data, you could provide a straight visual description of the image for the img's alt. For example, which data is shown on which axis? Not all screen reader users will find that helpful, but there are two things to keep in mind:
1. If a screen reader user moves into the figure with certain keystrokes, the text of the figcaption will be announced as the figure's accessible name or description. So the presence of alt text need not in any way block them from getting to the data.
2. Are you catering for all possible screen-reader-using audiences? Okay, if I'm reading an article about the benchmarks between two databases or something on a blog, it's more personal/for work and I just want the data. But what if I'm in a classroom setting and need to tell my students how to read this chart? If I don't know anything about the layout of the data, I can't do it.
A straight visual description of the diagram is probably inappropriate for alt text: too long, too wordy; it’s the longdesc problem again.
I’m not convinced that there is a properly correct solution here.
We're now entering the realm of what represents a caption and what doesn't. Given my earlier point that the figcaption text is mapped as the accessible name or description for screen reader users, interactive elements inside the caption should be avoided because they don't make sense when spoken inside a flattened, plain text string. So to answer the specific question, "now what?" Don't put the link inside the figcaption, put it inside the <figure> as a sibling of the image (or inside a container which is a sibling of the image).
To look at it another way: I might be inclined to say that caption text should make sense when presented with the accompanying image in a non-web context (e.g. a printout). This is why captions are often used for credit lines, attribution info, etc.
> I’m not convinced that there is a properly correct solution here.
Without a more specific use case, it's difficult to make a recommendation. However, I will say one thing that I've found to be universally true: the power of the image description is often underrated. I've had many conversations with designers, developers, content editors et al, where the assertion has been made that there's not much to describe in a particular image. And then as a blind user, I have multiple questions about what it shows, the answers to which can make it into the descriptive text.
This is often a lightbulb moment for many, as they realise that actually, all those details I asked about were subconsciously filled in/processed, and they just didn't think about them. Data is the same.
Is a bridge too far. Sure you should summarize the key takeway of a chart, but a chart has a lot of detail that sighted users don't need to reread in a worse layout, but blind users need a way to access.
There’s no good way of exposing lengthy information about a chart to screen readers. Don’t try doing it via alt, it’s a bad experience; and don’t try doing it by screen-reader-only text, that just gets confusing. The longdesc attribute was an attempt to do this, but it failed to gain traction among users or assistance tech. Consensus now is that you should instead include in the caption a link to a page that focuses just on the chart, which can then include more detail for the screen readers.
aria-hidden="true" will make the element completely invisible to the screen reader software, whereas setting aria-role will tell the screen reader "hey there is something here but it's job is purely aesthetic", and then the screen reader can determine what it wants to do with it.
There is no such attribute as "aria-role", only the single word "role".
> aria-hidden="true" will make the element completely invisible to the screen reader software, whereas setting role will tell the screen reader "hey there is something here but it's job is purely aesthetic", and then the screen reader can determine what it wants to do with it.
This is accurate, but you should also ask yourself about design intent if you have the knowledge to do so (or can consult with someone who does). If you have decided that something should be hidden from a screen reader user, and have verified that your intentions are correct, aria-hidden is the way to go. Many accessibility bugs are caused by people using something like role="presentation" because they wanted to leave it up to the browser and/or screen reader to make a decision. The problem is, those software decisions are often wrong and inconsistent, leading to support requests and hard-to-track-down bugs.
Note: the above applies across the board, not just to images. The correct way to mark an image as decorative is via alt="" on the img, and you should be careful applying aria-hidden to anything as it can be extremely destructive. No ARIA is better than bad ARIA.
Specifically I’m finding fault with “the screen reader can determine what it wants to do with it”. This isn’t true because the screen reader will never see the image, because the browser removed it from the accessibility tree.
But yeah, https://www.w3.org/TR/wai-aria-practices/#presentation_role lists this as the first of three common uses of role=presentation:
> Hiding a decorative image; it is equivalent to giving the image null alt text.
But still I echo how jscholes ends, and how the WAI-ARIA Authoring Practices document starts: No ARIA is better than Bad ARIA. Be careful what you do if you’re straying from the beaten track, and test things out. In view of this, I will confirm that I have not tested anything that I have said in this comment in order to verify it, though I believe that my mental model of how the accessibility tree and the mentioned details works is accurate.
Similar to the discussion around functional CSS [1], HTML vs. CSS is a separation of technologies, not a separation of concerns. Neither approach is _wrong_, they just come with different trade-offs.
[1] https://adamwathan.me/css-utility-classes-and-separation-of-...
Web design practices are far too unpredictable, and you can't rely on them to extract semantics.
I see two types of content. Published content and User generated content.
Published Content is any content produced by employees who run the website or customers who are hired by the employees to work for them. Here content is controlled and there is some sort of oversight as content gets published and there is responsibility on publishers. Generally there are some monetary incentives to the publishers to do that.
User generated content is any thing posted by any user. There are no monetary benefits to the users themselves. Not much oversight. Though there might be community guidelines, they are often not enforced. Consequences of not adhering to the policies might not matter much to the user.
From accessibility standpoint, there is not much we can do for the user generated content other than educate them. In the end, it's user's decision whether to adhere or not.
In case of published content, website owners have total control on what goes out to begin with. They can proactively enforce accessibility guidelines.
For the comment in discussion, my observation is that glyphs are popular for user generated content rather than published content. And from accessibility standpoint, it's an OK trade off.
But as you said, for an industry that systematically ignored the problem for 10yrs, I would rather push them for generation of better accessible published content than user content and hence i said it’s a trade off.
I also wonder how ML can potentially help here. For example, for images without alts, automatically populate them.
My guess is screen readers can have trouble telling what it really says.
<span aria-label="like this example"><span aria-hidden="true">𝕝𝕚𝕜𝕖 𝕥𝕙𝕚𝕤 𝕖𝕩𝕒𝕞𝕡𝕝𝕖</span></span>
I've written a post[1] about this and thought I'd implement it in one of my services as an example. I haven't seen any example of it live yet.
Getting those services to include such markup in the copy/paste version would probably solve this problem for most occurences. Note that (a) the original text is known to the service and (b) copy/paste content doesn't have to match what is displayed (e.g. "pastejacking")
It's actually the humans who don't know what it really says. We see 'some weird looking glyphs' and mentally translate them to letters we know. This quirk of the human brain is how we can read a random jumble of letters from different alphabets as English words.
Screenreaders on the other hand know exactly what it says and they read it out precisely how it's written.
I've seen it many times here at least. Just add an addendum!
E.g. 𝖙𝖍𝖎𝖘 get read as "Mathematical bold fraktur small t, mathematical bold fraktur small h, mathematical bold fraktur small I, mathematical bold fraktur small s"
It should aboslutely be "smart" enough to simply say "fraktur this" -- to recognize a string of letters of the same style and specify that once, and to interpret the text as a word.
It is the job of screen readers to convert the visual meaning to an auditory meaning as clearly and concisely as possible. If it isn't doing it concisely, then the screenreader is failing and needs some better engineering.
(* I usually hate when 'just' is used this way, I'm sure it's a minefield in some respects. But still more robust than trying to optically interperet what amounts to captchas in some situations :)
iconv('UTF-8', 'ASCII//TRANSLIT', $text)
When I wrote the parent comment, I tried it real quick with a REPL on my own machine, but apparently I don't have the right combination of environment variables or locales or God knows what. Didn't feel like chasing that rabbit into his hole.
https://twitter.com/jypnati0n_/status/1303012163766743041
Seems like the screen reader could have a "say what they mean" mode to pronounce "𝒕𝒉𝒊𝒔" as "this". I assume the legitimate use of Unicode mathematical symbols like "𝒕𝒉𝒊𝒔" is much less than the pseudo-font usage.
Understandably though, screenreader software probably isn't as fast moving as other industries. If there was an open source screen reader I think I could easily make a pull request to solve this particular problem, if it is a problem.
I was doing it to work around the limited formatting available here, but I noticed a couple hours later that my comment was transliterated into ASCII. Given the time delay, I assume it was done manually. (Dang, was that you?)
ASCII English "Latin" letters. Not "the" alphabet or "normal" letters.
If people are going to do strange things like this en masse, perhaps the screen readers could implement some normalisation rules.
I assume he's talking about using unicode characters that visually similar to english letters, but are not actually english letters.
They're chosen because of some visual elements, and are hard, if not impossible to pronounce for text-to-speech.
Instead of "clickable clapping hand sign quick graphic emoji" or whatever ridiculouslness it's saying...
...shouldn't the screen reader just say "clap", perhaps in a different pitch or intonation that one signifies "emoji"?
The tweet can be perfectly read by a human being as "If clap y'all clap don't clap" etc... with the "clap" in a higher pitch or more emphasized intonation.
The emoji are fine. Screen readers just need to improve how they read emoji. Which doesn't seem particularly hard to engineer.
There's also the problem of Emoji misuse, for example, using , pronounced as "globe showing americas", as the emoji for Earth.
Have you tried recently? "OK Google, read me this web page" does pretty much what you'd expect.
There's nice quality of life features of people who can see. The page scrolls as it's read, and the current word is highlighted.
"OK google zoom out the map a little" (while driving)
"OK google scroll down"
"OK google insert a waypoint for the next grocery store" (while driving)
"OK google turn off the alarm"
"OK google switch the map to satellite view"
"OK google what color is the Uber I just called"
My personal pet peeve, though, is the absolute and deliberate refusal of Google to voice-type the word "o'clock." It is bizarre, and I say it is deliberate because it's not confusing it for another word. No, you can stand there and say o'clock over and over again, and the circle will keep pulsing indicating it's listening to you, but it will type nothing. It's infuriating because it stops you from being specific. You say "start at four-fifteen" and Google knows to type "start at 4:15". But if you say "start at four o'clock" you just get "start at 4" and there's not a damned thing you can do about it. You can say "We'll go at one o'clock, two o'clock, four o'clock, five o'clock" and it just types "we'll go at 1245"
Why?!
This one in particular. Or "what are the best couple restaurants on the way" followed by adding it to the route.
I gave up on voice control because "ok google play my anime playlist" only worked around 40% of the time (even though I spoke it clearly and it transcribed it no problem). The other 60% it would play Terrordome by AniMe which is not remotely what I wanted.
This is despite going out of my way to create a playlist named "anime" because of course there was no way Google Assistant would ever understand "ok google play 微かな密かな確かなミライ".
The more I think of it, the more I realize that Accessibility was always just an accidental byproduct. During the time when graphical displays were not widespread yet, even non-blind people had to deal with text interfaces. So there were many around. For instance, around 2000 I was reading guitar tablature with my braille display. That worked just fine. These days, if I go and hunt for tablature on the web, all I find are inaccessible graphical things. The only chance I have to find accessible tablature is to go and find a newgroup archive somewhere. This underlines my point, accessibility for the blind is something from the past. These days, nobody cares about us anymore.
I care. And I'm trying to do something about it - making HTML5 <canvas> elements more accessible to people such as yourself[1].
The key barrier I'm facing is getting people to take my efforts seriously. In particular, as a person who does not require (or prefer) assistive technologies to access the web, I have been making a lot of assumptions about what needs to be done to make canvas elements more accessible to end users. However I expect some of these assumptions are wrong. Or right - but implemented in a way that is not best practice or even very helpful.
What I need is feedback.
My latest attempt to get feedback was an email to the w3c-wai-ig mailing list[2]. I got one response back (by direct email) which led to a suggested improvement which I've ticketed up for action[3]. Any feedback that I can get from end users is not only welcome, it's essential!
I don't expect my canvas library to take over the world; I do hope that it can act as an example to other, more popular canvas libraries to prove that canvas elements can be made accessible: there's no excuse not to make them accessible.
[1] - Scrawl-canvas home page - https://scrawl-v8.rikweb.org.uk/
[2] - Web Accessibility Initiative (WAI) Interest Group (IG) Discussion list - https://lists.w3.org/Archives/Public/w3c-wai-ig/2020JulSep/0...
[3] - Scrawl-canvas GitHub issue - https://github.com/KaliedaRik/Scrawl-canvas/issues/8
In my experience as a web dev it's simply that the "market" of blind people is too small for many companies to justify the expenses. I work in a B2B shop which sells a fairly expensive product so our potential visitor base is maybe in the low 1000s of people.
I'm certain there are at least some who are visually impaired and are unable to use our latest online offerings. However, comparing the ROI of fixing that versus the ROI of implementing a new feature that helps ~99% of our customers lead to only one conclusion.
It is my believe that the only route too improve the situation is through regulation. It worked for making public buildings more accessible in many places on this planet.
Threaten noncomplient entities with big fines and see the market adjust.
Nevertheless its a question society should at least discuss (and the conclusion may very well be that it is too great of a burden).
Many regulations have different rules for different types of entities (e.g. for profit vs non profit or by number of employees).
That something loads faster or has better support for blind people or renders better on my iPad doesn't mean that it's more relevant to my search. I'll wait 30 seconds longer for a webpage to load and stomach its crappy design if it has more accurate and relevant content, so I don't think it makes sense for Google to throw its weight around like this.
I mean, we're all on HN yet it's atrocious on my smartphone. And <table> spam probably sucks for screen readers. Doesn't mean something you're not looking for should rank above it just because you can read that unwanted content easier if you're blind.
Ideally you could opt in to additional weights like "I'm on a slow connection" and "blind-friendly results first please".
If I am penalised not for relevance but for accessibility then I fix the accessibility.
I am then both relevant and accessible and the world is a better place.
We shouldn't lose that content which can still be very relevant just because they're not following the current trend of constant website updates.
To a blind person, whether a website works well with a screen reader is extremely relevant to their search. Why are their needs less important than yours?
> Ideally you could opt in to additional weights like "I'm on a slow connection" and "blind-friendly results first please".
This just makes it easier for websites to bloat up or ignore accessibility. I have no issue with search engines penalizing websites to encourage them to take accessibility seriously.
It will be improving the quality of search for non-blind users because websites will be structured better for Googlebot.
Any gimping will be temporary as the websites rush to comply.
The gimping can be non-existent if Google simply announces ahead of time that accessibility will weigh more heavily. That'll give devs time to adjust. Look how Google pushed the adoption of HTTPS.
I think it would help if everyone tried using their own product through accessibility-tools from time to time.
Thank you for carrying out testing. I should note that, unlike the probable majority of HN readers, MacOS and Linux are nowhere near as popular among blind users as Windows. MacOS has a decent market share (around 10-12 percent or so), but the number of screen reader users on Linux is almost insignificant.
https://bbc.github.io/accessibility-news-and-you/accessibili...
Microsoft has documentation on the built-in Narrator: https://support.microsoft.com/en-us/help/17173/windows-10-he...
Apple has docs about VoiceOver on iOS and macOS: https://help.apple.com/voiceover/info/guide/
On Windows, JAWS[1] and NVDA[2] are the most popular, the latter of which is open source. On MacOS, the only choice for GUIs is VoiceOver[3].
[1] https://www.freedomscientific.com/products/software/jaws/ [2] https://www.nvaccess.org [3] https://www.apple.com/voiceover/info/guide/_1121.html
Although it is common for people to refer to vim as a command-line program, edbrowse is a command-line program in a stricter sense: the user types a line of text, then hits return, then the computer prints zero or more lines of text, then the user types a line of text, etc. (vim is a rewrite of an earlier program named vi, which is short for "visual", a name chosen to emphasize the fact that it departs from the strictly line-oriented interface of earlier Unix editors.)
I can see your point because for many years I used cd, ls, mv, etc, to do all my file management and all of my browsing around my local file system. When I switched to software (Emacs's Dired subsystem) that let me specify the file to be acted upon without my needing to type the name of the file, it was a distinct improvement. (I usually use the page-up and page-down keys to find the page containing the file name I want, then use the mouse to specify the file.)
Thanks for your reply.
I beg you, please don't test your website for accessibility by using edbrowse.
For sure. If your website does work in edbrowse, it may imply that you have a decent chance of making it accessible because it doesn't use a ton of dynamic interactions or page updates etc. But it doesn't guarantee it. You could still have issues with heading hierarchy, communication of control state and other factors. In some cases, edbrowse may even lull someone into a false sense of security, because it simply can't present certain aspects of your page. But when displayed in a mainstream browser, they may be inaccessible.
In a nutshell, it's unlikely that you can draw any meaningful conclusions after testing with edbrowse, be they about the accessibility of the page or the typical experience of a blind user on the web.
By far the easiest screen reader to test with is Microsoft Narrator because it is included with windows.
I guess this makes things hard for a screen reader since HTML isn't saying what's what anymore.
At a deeper level, you have to appreciate that browsers are built around the “separation of concerns”:
- html for content
- css for layout, look and feel
- javascript for behaviour
The front-end community has some loud voices at the moment telling us that these are the wrong separations; that the styles for a component go hand-in-hand with their behaviour and semantics. I’m not getting into that debate here. But I do want to say that this newer interpretation of the “concerns” applies to code you write for your application, and is (currently) not how browsers are constructed. It may make more sense for you as a web application developer to structure your code by colocating your layout and behaviour solutions in one file, and in that way you’re more likely to use <div> and <span> over more expressive elements. But that’s not what your users’ browsers are expecting you to do. They’re built around the older separation of concerns. And they’re built to amplify the strengths of the three languages they interpret. So that <div> tells the browser “i want you to treat this content just the same as you treat any other content”, where a <h1> tells the browser “add this content to your document outline, expose it as a section heading to the accessibility tree” as well as reminding it to apply the default styles.
Attack the problem (unwanted styles) at the right level of separation (at the styles level).
It opens a sidebar on the webpage you have open showing you accessibility issues: incorrect heading orders, unlabeled forms, missing alt tags, bad contrast, etc. It also can walk you through the spec in plain English to help you understand why you need to make the changes it suggests.
He says "click here" isn't helpful, in isolation but that's not helpful to a sighted person either. In context? Do screen-readers fall over on links present mid-sentence, like saying I have the article on my block you can [click here] to read it?
https://www.deque.com/blog/text-links-practices-screen-reade...
What drives me mad are things like buttons or lists on a form that aren't even visible to the screen reader, date fields that pop up an inaccessible calendar just to fill in a text box, but the text box is read only so you can't just type the numbers, and so on. It's not the lack of image descriptions or even headings that is the problem with modern sites, it's that some are completely unusable with a screen reader.
Traditionally I always run screenshots and colors through colorblind check simulators, though I'm sure there's a lot more that I can do.
Now try to use your own website with a text-to-speech (TTS) engine and your keyboard.
No joke, recreating the users situations is often a cheap and easy way to find problems.
For example I like to check a design by setting the network speed limit with the browsers dev tool to 32kbps, to see how long it would take to load on a bad connection.
I'd urge everybody to take a simple unstyled HTML page as a markup. If your page looks bad without styles, you are doing something wrong. If the navigation is cluttered and convoluted in unstyled mode you are doing something wrong.
If your page is less usable than a basic well structured HTML page, go back and make it a basic well structured HTML page and add styles from there.
In the article most of the annoyances boil down to crappy html markup and unclear navigation. These are things that are easy to fix without any special accessibility knowledge and go a long way in improving usability for everyone.
As for getting it to the front page, having a few early votes are critical. Then it will be seen by more people, and it snowballs from there. So it's mostly luck/timing.
I will try to improve on that, thanks author!
Some tips:
- blank alt text is better than no alt text: alt=““ should be fine if the image is pure decoration
- if a photo repeats some text next to it (such as an avatar image beside a user name), it could also be blank, or “User Name’s photo”
- when a company logo links to the home page, an alt text of “Back to hone page” is probably more useful than “Company logo”
I've always used title in the anchor tag for that rather than the image alt text (title="back to the home page" in the anchor; and then alt="Company logo" in the img tag). That way you're properly describing what the image is and also providing information on where the associated link goes.
Can anyone here with experience with screen readers clarify if that's an effective approach?
As far as I know, screen readers don't read the title tag by themselves, though users can request it. So your approach works. And I think it is also has nicer semantics.
Personally, I prefer to use a text link with the company name, then move the text out with css and add the logo as a background image. This also works great in text browsers of course, the company/site name just becomes the h1 of the page.
However, I think it’s valuable to ask yourself “why does a non-visual user need to know the company logo is here?”.
never thought of it this way, but this makes sense. Thanks.
Is "user uploaded photo" good enough for example? The best would of course be to analyze the contents of the photo but that is simply not realistic for the stuff I work on.
What are the images for? Do they have text accompanying them? Are there themes to the images? Can you convey the same meaning and intent another way? Can you educate your users to help you out?
The answers to these questions should guide your solutions to access requirements.
Alt text isn’t only about providing a description of an image, it’s one tool in a toolbox to improve access to information.
I have Firefox set to block all autoplay. This is generally excellent, stopping all those annoying videos on news articles from playing (seriously, does anyone like those things?). But I am surprised at how many things break in some way, using a <video autoplay> with no controls: like product websites that have short videos throughout the page, or imgur on a video. You end up with the page loading and just no visual indication that there’s a video that you could play at all, and are left to just guess “maybe it’s a video” and right click on it and click Play.
I wrote myself a simple user script a few days ago to experiment with just adding the controls attribute to all videos on page load, which will probably improve most things—though some will add the video element after page load, or remove the controls attribute gratuitously—in imgur, right click → Show Controls, and next time the video starts (e.g. unpause, or buffering completes, or the video loops around) it’ll kill the controls again for utterly mysterious reasons). I’m contemplating putting a MutationObserver in that flips the controls attribute on every time it gets switched off.
It's one of the many wars on the web; websites want to push content, users don't want to be annoyed.
Disclosure: I'm a developer on the Windows accessibility team at Microsoft, working on UI Automation and Narrator among other things.
Semantic HTML5 together with alt= image attribute covers the majority of problems with aria-label*= attributes covering the edge cases.
Is there a good get-started guide? How can I measure the “accessibility” of my website? Is there a free screenreader I should test with?
Most images on heavily visited social networks like Facebook are not curated by the site owner. They are uploaded by users, and the alt text can only be as detailed as the uploader bothers to type in. Most people don't bother at all. If required, they'll type in garbage to get through the form as quickly as possible. This is not something that site owners can easily control.
This would seem to be a prime opprtunity to whip out modern image recognition software, either on the server side or as part of the screen reader. We've all heard about server side image recognition, but there might be privacy implications about exposing automatically recognized details as alt text. Are there any screen readers that can analyze an image and output something like "an image of a woman and a baby in a playground?"
I was just thinking about this the other day and found that FA has a good guide on accessibility in these scenarios here: https://fontawesome.com/v4.7.0/accessibility/
"Image may contain: 5 people, including <Redacted>, people standing, sky, cloud, shorts, twilight and outdoor""
Sure, I can follow the rules, and try to use a screen reader, but honestly, I'm terrible at using those tools. I can't _think_ like a blind person. But I'd definitely pay one to give me honest feedback.
If you really want to make life easier for blind people (and many other users as well), makes sure you are also sending the plain text version along with the html.