This is all good top-level stuff, but one thing I'd quibble with in this article is something that they don't say, except in the linked article about writing alt text - the vast majority of images are decorative, and those images should have an empty alt attribute. I see far too many images with pointless alt text because "you need to add alt text to all images". The easy way to think about this is to read the page as if the image alt text was part of the body copy. So if it goes like this:
"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?
I strongly disagree. Empty alt text means no image description. Think about that. You are blind. Your Screen reader tells you "image", nothing more.
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.
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.
Rereading my comment I see that I only said "empty alt attribute" at the beginning and then started saying "no alt text", which is much more ambiguous and easy to misinterpret.
<rant>
The thread till here is a perfect example of how discussions/debates should be like on the web. Someone expressed an opinion, someone else expressed an opposing opinion (misinterpreting the first opinion). Both opinions, if interpreted correctly, are valid, and the person who misinterpreted admitted it. Beyond that, (and note this) the author of the original opinion also apologized for being confusing in his statement of his opinion. Well done!
</rant>
There's no such thing as an alt tag, you're mixing up tags with attributes.
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.
>but if there were a time when empty alt attributes caused problems, it was back in the 90s.
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.
I was paying attention to this stuff by the turn of the century and best practice back then was the same as it is now. Screen readers have come a long way, but they could handle empty alt attributes correctly back then as well. I just checked, and the HTML 4 specification has been advising people to use empty alt attributes in this situation since 1997.
> 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.
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).
It should be that alt="" means the author specified that the image is purely decorational, missing alt means the author did not specify anything. Do screen readers really say "image" when presented with alt=""?
They used to. But your comment made me search a bit and it seems most don't any more, you have to turn that on.
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.
My view is that most images are decorational in the terms that we're talking about. You can view a photo of a burst dam, to take one of my examples, but a description of the scene should be in the article already, and therefore any further description is superfluous. The "should" in that sentence is doing a lot of work though - I don't think people consider this kind of stuff much at all, not on a deep level about why they're doing things. My first proper web job was in the BBC in the late 90s, and it was a really steep learning curve but has stood me in really good stead when considering this kind of stuff.
I have trouble wrapping my head around this. When I think of decorational images, it's mostly back to times when we used spacers or built table layouts with sliced images. I drank the semantic cool aid. Decoration should be separate from content.
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?
> Of course a stock image in an article is not really important and may not add much value
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.
> back to times when we used spacers or built table layouts with sliced images
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."
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.
The issue here is that despite screen readers, text is simply not the same as images.
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.
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.
> I feel like this is something where AI can actually shine: generating descriptions of images and video for blind people.
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".
I wouldn't consider generating descriptions a "solved problem". There has been progress with AI, but part of the issue is that image classifiers are trained to describe the objects in the image, but not necessarily the feeling or meaning of the image.
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.
I think it might already be there - I just right clicked in Chrome to see what options I could pull up for an image, and noticed a "Get image descriptions from Google" option
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.
The way it's a standard feature on so many blog articles to lead with a big pointless unsplash image vaguely related to the content drives me crazy. What a waste of resources.
Photos, illustrations, ... basically always should have an alt-text. a) They are added for a reason for sighted users (e.g. to set atmosphere), a non-sighted user should be able to understand what is intended b) not all screen-reader users are entirely blind - they can see that there is an image and want to know what it is.
Divider lines etc done as images should have an empty alt-text to be skipped.
Not sure I agree with your first point (I do think people add pointless images though, which muddies the water somewhat) but that's an interesting point about partially-sighted users that I hadn't considered before. There's clearly not a binary blind / not blind distinction in people. Thanks for pointing that out - I'll consider that in future.
This post and the above comment prompted me to add alt text for an image on a landing page I’m working on.
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.
I dunno. I sort of get where you're coming from, but I think "describing the image with words that evoke that mood" is a bit like explaining why a joke is funny.
> "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..."
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.
Regarding the first example, even if the photo seems inconsequential to you, it's part of the narrative content of the article, perhaps to set a tone; it's an illustration, not simply decoration. Sighted and non-sighted users alike can use it to determine and judge the perspective and tone of the article, even if it doesn't have any other function.
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.
It is unfortunate that nonexistent alt attribute is treated differently from empty alt attribute on images. I would prefer to add role="presentation" instead.
> I would prefer to add role="presentation" instead.
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.
Decorative graphics is prime example use case in WAI-ARIA docs for the presentation role. Its purpose is to remove the element from the accessibility tree.
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.
I was going to come here and ask about better alt-text until I read the linked page you referred to (https://bighack.org/how-to-write-better-alt-text-description...). I still have a question about a sight-impaired person's perception of what that image represents. Do you form an image in your head matching the text? Is this different for those who are blind from birth versus those that lost their sight after some time? Should the image be part of the "story" of the page or should the story stand on its own? And finally, for the case above where the image is decorative (as defined here: https://www.w3.org/WAI/tutorials/images/decorative/) would you prefer that the empty alt tag recommendation is used (and do screen readers recognize that semantic).
If you look at most images in web pages, I'd argue that the vast majority are decorative or impossible to explain in a meaningful way. I've been building sites since the late 90s and I think this is probably a throwback to the times when we used to generate images with text in them, which doesn't really happen any more. Although there are probably cases where it's still relevant - I just can't think of any off the top of my head.
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.
What we need in web pages is a way to mark an image as purely decorative, as recent versions of MS Word have. When so marked, a screen-reader will skip that image as if it doesn't exist. This is a big improvement over the past reality of hearing "Image: decorative bracket" as a document is read. This is what HTML needs.
> What we need in web pages is a way to mark an image as purely decorative
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.
What about people with very poor eyesight, who can see the shape of the website, but can't decern words or image details. They may want to know that the dark square they perceive is a picture of the burst dam.
I started writing an article in March entitled “<img alt> should be empty”, arguing the radical position that every image tag should have an empty alt attribute. I don’t quite hold that opinion in reality, but it’s pretty close. I stopped writing it because I was poking a few too many holes in my position, but I still hold to the bones of it.
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.
> Hiding the image in this way because it has been fully described is thus perfectly reasonable.
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.
OK, thanks—checking it with real users is the main thing I still wanted to do with this, and I was hoping someone in the know would respond! (I was going to have to find someone to ask if I went ahead with the mentioned article, definitely couldn’t publish without that.) But my problem is this: I see no reasonable value for the alt text; every option available to me is claimed to be wrong for at least one reason: you shouldn’t duplicate the figcaption, and you shouldn’t omit alt, and you shouldn’t have a blank alt, and you shouldn’t just say “photo” or even “the photo described by the caption”, so… what’s left? I can think of no other reasonable alternatives. So blank alt was feeling the least bad to me.
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>?
I'd argue that the figcaption can't contain an adequate description in pretty much every case. "Figure 3: results of Benchmark Q, showing X to be 40% faster than Y." is appropriate only for the minimalistic bar chart with only two bars, and already there it's pushing the limits - it would often be appropriate to just say "Figure 3: speed of X and Y in benchmark Q" as the interpretation and conclusions from the two bars is a separate, different thing which could be in the text. Perhaps to the reader it's not relevant that X is 40% faster than Y, but rather that X can do the thing in 5.6 seconds - which is clear from the bar chart, but not from that proposed figcaption.
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.
> I'd argue that the figcaption can't contain an adequate description in pretty much every case.
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.
This style of caption I’m describing is regularly only very broadly describing the figure and picking what the author thinks is the most relevant detail. It’s typically not describing everything—nor would alt text, because that’s too long for alt text, which needs to be fairly short.
> 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>?
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.
> But I’m going to put that link to the full diagram in the figcaption, because I want it to be there for sighted users also. Now what?
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.
> basically always be described in the visible text anyway,
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.
I think we’re in agreement, just that you understood what I wrote a bit differently from how I intended. By “described in the visible text” I didn’t mean “expounded at length”. I’m talking most commonly about the sort of captions newspapers printed with images, typically 5–30 words; but also about things in the text that refer to the figure, like “here are the benchmark results:” and “we see that X is 57% faster than Y”.
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.
I think ideally those charts would be SVGs that can have elements with their own ARIA labels and be navigated by a screen reader. It would be very clumsy to describe an entire chart in an alt text string.
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.
I wouldn’t describe role=presentation like that. Rather, it says “ignore what you know about what this element should be, pretend it doesn’t exist and only consider its children”. Technically, that is “replace this node in the accessibility tree with its children”. And then in the case of <img> specifically, it doesn’t have any children, so the effect is removing the entire thing from the accessibility tree, same as an empty alt attribute or aria-hidden=true.
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.
> 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.
Decorative images should be in your style sheet, not the html document. I know this purity isn't always possible with every design, but if you care about blind readers you'll change your design, I guess.
> Decorative images should be in your style sheet, not the html document.
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.
From comments in other threads, I know of one other thing that makes these people's lives even harder than it already is: thїs їn рaяticиlaр. Yet It's been becoming annoyingly popular.
I know it's pretty common in user generated text like comments, titles of the posts, etc. I'm not sure if they are a popular pattern in website content. I wonder if there are any popular websites that actually use this pattern. As it would be super bad for their business from SEO pov.
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.
I get what you mean. However, I dont agree that "we" cant do anything about user content. Users will use the technology that is provided to them. If the tech providers dont care about accessibility ultimately, they will create tools that make it easy for users to generate inaccessible content. So I dont agree. It is not something the industry can do nothing about. It is simply something the industry is systematically forgetting about in at least the last 10 years.
I totally agree that if made a priority industry can definitely create better tech that leads to more accessible content.
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.
Not sure if HN approves (it removes emojies at least, this went fine it seems), but there are glyphs that look like the alphabet/normal letters, but are not really the same characters, like these: 𝒕𝒉𝒊𝒔, 𝖙𝖍𝖎𝖘, ⓣⓗⓘⓢ, 𝕥𝕙𝕚𝕤, ㄒ卄丨丂, ｲんﾉ丂, ꙅiʜƚ, 🅃🄷🄸🅂, sıɥʇ, 𝓉𝒽𝒾𝓈
My guess is screen readers can have trouble telling what it really says.
This can be seen quite a bit on Twitter, both in usernames and the tweets themselves. Personally, since I think human behaviour cannot be completely fixed but can be nudged in the correct direction, I'd like to see services implement something like alt text for text, especially usernames. This way people can use different characters to be as creative as they want, but provide an accessible version for screen readers. Something like this example:
<span aria-label="like this example"><span aria-hidden="true">𝕝𝕚𝕜𝕖 𝕥𝕙𝕚𝕤 𝕖𝕩𝕒𝕞𝕡𝕝𝕖</span></span>
The alternative would be restricting the use of these characters, but this would kill many valid use cases and you can't just forbid non-latin characters on an international service.
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.
I like the idea, but the de-Unicodifier would have to use the current user's locale - de-Unicodifying certain characters (e.g. Cyrillic that look like English) would have unintended consequences if you just assumed they're meant to be English.
My idea was that this would be something provided manually by the users, just like you can specify alt text for images on Twitter right now. I know many wouldn't bother. But at least some would, and it would make using an upside down nickname possible for me again. :)
I imagine most of these "stylised" effects are generated by services like https://yaytext.com
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")
My guess is screen readers can have trouble telling what it really says.
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 agree, and I can only imagine how aggravating it must be to be a user with a screen reader having to (mentally/programmatically) parse the very "clever" strike-through-simulating special-purpose Unicode text some user decided would suffice for "real" strike-through text, just because HN is, uh, persnickety, with its allowed characters...
I've seen it many times here at least. Just add an addendum!
That's obviously not true. Communication is a two-way relationship. You literally can't be an effective communicator on your own. If you write something in a way that can't be understood (with a little effort) by the reader then you failed to communicate well. If the reader is using a screenreader and you wrote in silly characters then you failed to communicate effectively, and you didn't convey anything at all regardless of what you might have meant.
Someone posted a video on Twitter about this. What happens is that it reads out the meaning (similar to the unicode names) of the symbols.
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"
IMHO, the onus is on the screen readers to improve.
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 don't think you'd need to use OCR for that. Just* use transliteration tables to map those characters to the base characters.
(* 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 :)
There are quite a few libraries for converting arbitrary Unicode to some subset while preserving as much meaning as possible (presumably by embedding such tables), and they generally work pretty well on this kind of text.
in my work to make sure I could accept arbitrary Unicode from users, and also send that same info as ASCII to legacy systems that mangled UTF. It worked really well.
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.
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.
It would seem to me that this would be a simple problem to solve for screenreaders as they are just 1:1 mappings, and in many cases even consecutive blocks of Unicode characters.
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 once used Unicode to set off some fixed width text inline with my comment. (Or, I think it was italicized? Don't remember exactly).
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?)
Not Cyrillic in particular, all scripts(I just happen to have Cyrillic layout hence the reason I used it for my example), but if you go around blogs, twitter or other websites, there are tons and tons of people mixing those up to look fancy or whatever it is they are trying to do. It's a nightmare for those of us who know several alphabets and an even bigger nightmare for those who need to use screen readers.
Something of the sorts could be implemented but this would be an attempt to make something idiot-proof. And from my experience, nothing can ever be idiot-proof. To quote Mark Twain: "they will drag you down to their level and beat you with experience".
Seems like it's screen readers that ought to improve their reading, no?
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.
Also putting dozens of emojis in a Twitter handle. A screen reader has to read them all before the actual tweet is read. It's even worse with the new, politically correct emoji containing skin tones, as they're much more verbose, and the sighted don't even notice the difference. Sad face, light skin tone, sad face, light skin tone, sad face, light skin tone.
There's also the problem of Emoji misuse, for example, using , pronounced as "globe showing americas", as the emoji for Earth.
One thing that bothers me is how all-or-nothing visual assistance on today's smartphones is. It expects you to either be blind or be perfect. It baffles me I can't say "Ok Google, read me this web page."
I wish it would quit treating two places with identical names as equally relevant no matter what their relative distances. Gee Google, did I want the one that's ten miles away or the one that's 186 miles away? Being able to say "take me to the Home Depot that's beside a Walmart" would also be nice.
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"
I would be goog4life if I could specify 'The cheapest gas station next to the interstate within the next 30 miles in the direction I am already traveling'.
Well hot damn, it works. Fascinating how the TTS voice is completely different from, and about a thousand times more pleasant than, any of the standard voices.
According to Google employees, this goes through the cloud, so can be much, much better, while sacrificing responsiveness, which is crucial for a normal screen reader.
To me the older on-device was much more pleasant than the current one. In fact almost every alternative TTS system like the old SVOX and Ivona voices sound better than the current selection of Google ones. It's like someone turned the treble knob up and no matter which voice you pick they sound screechy.
Honestly, my issue with Google Assistant has always been how inconsistent it is.
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 微かな密かな確かなミライ".
For me the reliability has taken a nosedive over the last couple of years. Lately it's started capitalizing random words for no reason. I can just have a random sentence and it will Decide half of it is Proper nouns.
Another blind user here. Indeed, modern web technologies and developers are killing my productivity. At first, it started to become increasingly hard to read something with a text browser. For at least half a year, no github wiki rendered in lynx at all. I am not even sure if that is fixed now. So over time, I realized I need a modern browser. These days, I have a dedicated Windows machine for doing things on the web. But it doesnt really help a lot, because even with a modern screen reader and browser, more and more sites are practically unusable.
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.
> 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.
I feel for you and am very sorry that you have to deal with it.
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.
I am of the opinion that the problem start with the ROI argument. Apple has managed to do the right thing and deliberately ignore ROI when it comes to accessibility. Why can they do the right thing, and the rest of the world can not be arsed to work for the good of the society?
I think only Google can fix this. They need to more heavily penalize your page rank if your accessibility score is low. The 5 things the author lists are so simple. How much effort is it not to auto-play videos? Compare that to the effort web devs put into SEO tricks which the web devs aren't even sure works.
The problem with penalizing things outside of relevance is that you're just gimping the quality of the search results.
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".
Whilst it may not be relevant to you, I think part of this is that Google are in a position to incentivise firms to better serve users with disabilities.
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.
For better or worse (in my opinion, worse) recent iterations of the Google algorithm already severely penalize, or even drop, static pages that have not been recently updated. I suspect it's a big factor in making small academic and personal websites significantly harder to find than they were in the past.
Many current website trends (overlays, popups, animated/video advertising, sticky video players) make content less accessible even for people with mainstream access requirements.
> 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.
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 to blind users - their search results matter too.
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.
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.
If I were blind, I would try to do as much of my interaction with the web as possible in "edbrowse", a browser designed and written by a blind programmer:
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 am blind, have never tried Edbrowse, but it sounds utterly tedious. A Mainstream browser is the only option if you actually want to get things done. I use Firefox with the NVDA screen reader. It is often repeated that command line programs are naturally more accessible to blind people, but it simply isn't true in many cases. Most blind people I know prefer accessible GUIs to command line programs. Think of something as simple as ls - you have to read the file names with the screen reader's review commands, then if you don't know the exact spelling of the file you want you have to get the screen reader to spell it one letter at a time. You then have to type the command plus file name, and the only thing that helps is tab completion. In a GUI, you read the list of files with the arrow keys, stop on the one you want and press enter to open it or ctrl+c to copy or what ever. It is far less keystrokes to perform the same task.
You write, "You then have to type the command plus file name, and the only thing that helps is tab completion."
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.)
> If I were blind, I would try to do as much of my interaction with the web as possible in "edbrowse", a browser designed and written by a blind programmer:
I beg you, please don't test your website for accessibility by using edbrowse.
It's not that you are against a website's being tested with edbrowse; it just that you don't want that to be a substitute for testing using a screen reader and a mainstream browser. Do I have that right?
> it just that you don't want that to be a substitute for testing using a screen reader and a mainstream browser. Do I have that right?
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.
Please test with NVDA. It is free and very popular. Jaws is becoming less and less relevant mainly due to it's cost, and the fact that NVDA is perfectly usable for most things. If you do want to test with jaws, there is a demo that works for 40 minutes.
By far the easiest screen reader to test with is Microsoft Narrator because it is included with windows.
After over a decade of discussion about the semantic web and accessibility, after so many best practices and recommendations from experts, it breaks my heart that in 2020 we are back to that.
Too lazy to learn is one of the reasons. Should use framework/lib is the other.
Now people think that by not using frameworks you will have messy code and happily create even bigger mess of frameworks rope spaghetti.
You need a “style sized solution to a style sized problem”. As the sibling posters have said, you can use reset stylesheets, or write your own.
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).
For web devs trying to build an accessible web, I can't stress how great the WebAIM WAVE tool is: https://wave.webaim.org/.
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?
I've not used screen readers much, but you can skip through links as a mode of navigation, but if all the links are "click here" "click me" "click" "get the info" then it's harder to keep track of which links go where.
In addition to the points that pbhjpbhj and Grumbledour have made, in badly written HTML the 'Click Here' link might be in a completely different part of the DOM tree to the rest of the content. For example, a developer could create a <p>Content</p> at the top of the DOM tree, and a <button>Click Here</button> at the end, and then use "position: absolute" to move the button next to the content. Visually they're next to each other but if you strip out the styling they're miles apart. Screenreaders do a decent job of trying to figure out what link goes with the text but understanding HTML is a crapshoot at the best of times.
While I can't speak for the author, I have a few blind friends who use screen readers. They often access a list of all links in a page to navigate, but naturally, you get only the text of the link in this list. I suspect the same problems occurs if you use tab to go from link to link. Surrounding content is of course not read aloud unless requested.
I personally don't have a problem with that kind of link. I read comments one line at a time. The screen reader says:
"article on my block you can link click here to read it? "
I then press k to focus the link and enter to activate it.
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.
I'm a bit confused by it too but I can image quite often the click here button is some absolute positioned element that is not necessarily after the relevant text in dom.
I’d like to emphasise the author’s point about not making excessive use of auto playing sounds, from the perspective of a partially deaf person. Background noise / music is jamming that makes it hard to hear the important sounds, such as speech from TTS. Do you really need that stock audio on your instructional YouTube video?
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.
Curiously enough even using a command line Browser like lynx can be enlightening. You start to see all the crap.
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.
Or browse the site with CSS styling turned off. Firefox also has an accessibility developer mode (Shift-F12) but it mostly focuses on technical issues.
I was wondering the same thing coz seems to me users with higher karma has a much better chance that their posts surfaces. Wonder if the HN algorithm works karma into the equation?
I think there is a correlation, but only because people with more karma have been her longer and probably posted more stuff. So naturally some of their posts eventually will end up on the front page.
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.
Sometimes stuff gets reposted, and sometimes one or other of the reposts gets a bigger discussion or more upvotes, maybe because of the time of day, or maybe because of other things getting discussed that day that change the context, or whatever. I don't think it's really a problem?
As a web dev this is very interesting and I try to think about accessibility when I develop. But I must say I am pretty bad at making labeled forms and alt texts for images.
Always think about what an image is for, as well as what’s in it. Images are “inline replaced content”, meaning that they are considered part of the text content, not a structural element like a table, and they are “replaced by” their content. So imagine them as a text sized box containing their alt text, and then replace them with their visual content. In other words, read out an image’s alt text with the text from the nearest block level container. That’ll give you an impression of the context A blind user will experience your alt text in.
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”
> 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?
My screen reader knowledge is a bit dusty, so this might have changed:
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.
Sure that sounds nice, but what to do with user uploaded images? I cannot describe them with words since they can be whatever.
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.
In the context of your application, does it matter? (I assume it does, but it’s worth asking the question because all apps, and pages in apps are different).
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.
that's of course not perfect, but you can give users the option to provide their own description. (Twitter does it, altough they've sadly hidden it well, so only some niche bubbles do it)
I can do it, but for the app I work on I believe very few would use such a feature. But I'll think about implementing it if I have the time in the future
“Auto-playing audio and video” is confusing me: is it not standard across all browsers to let the user prevent autoplay of at least audio and unmuted video? So I feel like this should be an entirely avoidable problem, just by setting your browser so.
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.
My understanding from a thread a couple of days ago is that are workarounds to that on some platforms. One that was mentioned was turning the videos into animated GIFs, which can autoplay on Chrome and require a special setting on Firefox.
It's one of the many wars on the web; websites want to push content, users don't want to be annoyed.
I am in the process of building a small application that will have a lot of text. However, the application will be driven by a game engine that means it won't be easily accessible to screen reader software. Would there be utility for a blind person if I created a built-in method of reading the text and offering a blind-mode/low-sight mode navigation option that radically alters the UI? Is there a standarized API for the popular screen reader software packages that I can tie in to that my application can use?
On Windows, that standardized API would be the IAccessible2 interface. If you need a cross-platform solution it's probably going to be more difficult, at least I'm not aware of any cross-platform abstraction layer for accessibility APIs apart from Qt, which of course does a whole lot more than just accessibility.
Correction: The current official accessibility API for Windows is UI Automation. IAccessible2 (IA2) is an unofficial extension of the very old Microsoft Active Accessibility (MSAA) API. While IA2 has been crucial in making non-Microsoft browsers and other applications accessible, I wouldn't recommend that any new code implement it.
Disclosure: I'm a developer on the Windows accessibility team at Microsoft, working on UI Automation and Narrator among other things.
I’m just starting on a greenfield consumer-facing website for a client. We mostly work on business to business web applications so I’m really happy to finally make something “regular people” will visit. I’ll try better to make it accessible for less-abled visitors.
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?
There are some accessibility assessing tools like wave and lighthouse as far as I know. Free screen readers are Orca for Linux, NVDA and Narrator for Windows, and Voice Over in Mac and IOS. Also, Talkback and voice assist in Android with the latter being Samsung only.
I wish there were better technology around the use of alt texts on images.
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?"
On the subject of unlabeled links, my guess is that FontAwesome icons are often used as links these days and that screen readers probably don't deal well with them.
I dealt with a number of these issues 20+ years ago when working with nonprofit websites. My quick metric was "does it make sense and work in lynx?"...
I wish there were a service to hire blind people to test my website.
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.
I'm glad I read this article. I just did some HTML email templates and I didn't add any alt text (I'm not really frontend engineer and I didn't at all thought about a visually impaired person reading). I will add them now thanks to this article!
Emails are also a special kind of hell, because we often need to fall back on table layouts, which are painful with screen readers.
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.
"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?