Any web designer or developer with her heart in the right place knows that, to be accessible, every image requires an alt text. Except when it doesn’t.
Consider the common bio. For instance, this bio of Faruk Ateş. Among other elements, it contains an author photo, a page title (an h1 headline containing the author’s name), and a paragraph of biographical content beginning with the author’s name.
According to WCAG (not to mention every standards-oriented web design book ever written, including mine), it is good accessibility practice to provide alt text for those who cannot view an image.
But in this case it would be bad, because a blind reader would have to listen to Faruk’s name three times in a row: first, when the screen reader reads the alt text (“Faruk Ateş”), then when it reads the h1 title (“Faruk Ateş”), and lastly when it begins reading the paragraph.
In this case, then, it is better to use the null alt (alt=""), and that is what we did in the A List Apart redesign. [Actually we use a modified null alt ( alt=" ") because several popular older screen readers mistakenly speak the file name in the presence of a true null alt.]
As we crafted our templates, we discovered many places where an alt text would have been redundant, offering a blind user no new information not already provided by the page’s HTML text, and merely annoying that user with needless redundancy. Markup is an art, and the soul of that art (as with all design) consists of creating the best possible experience for the user.
The more you know…
Wouldn’t it be best to use “Photo of the subject” or something similar as the alt text? I assumed that the alt text should explain what the content of the image contains, not necessarily name the image.
Brilliant! Thank you. Just what I needed for ammunition. Now, to reload.
@Brad Bice 1:
That’s a judgement call. In your case, on your project, it might be best. We decided it wasn’t, here. Hearing a screen reader say “Photo of Faruk Ateş. Faruk Ateş. Faruk Ateş is a …” seemed like the kind of thing that would drive a blind reader crazy.
The “null alt” in the article is not in fact a “null alt”, as it contains a space character (U+0020). You meant to say `alt=””`, without the space, or simply `alt` in HTML.
Also note that the `alt` attribute may be omitted in some cases.
@Brad Bice This was my initial thought, too, but I suppose simply knowing that an image is there isn’t helpful. The point is the ensure, through accessibility, that no one misses important content by being physically limited.
@Mathias Bynens — you’re right it’s not actually null, but we prefer to keep the space, because without it some older screen readers, upon encountering a truly null alt tag, will read the value of the
srcattribute anyway.What screenreader or readers do you have for testing this kind of thing? I’ve heard of this a lot before, but I’ve never had the chance to actually use a screenreader.
I train a lot of people in content management, and when explaining ALT and text readers, I always tell them that sighted or blind, if they’re going to include a photo it should have contextual value – not be just a pretty picture. And that means there’s something to be said about the photo. “John Smith crafts widgets in his backyard shed by candlelight.” Can you almost see that photo? That’s what goes in ALT text. And if it’s just a pretty picture or supportive to the existing text, leave ALT blank. Don’t tease someone who can’t see the photo with “here’s a photo.”
@Joseph Russell — it’s been a while since I’ve tested it myself, but I know that some of the older (and more popular) versions of Jaws behave this way. My info is probably overdue for a refreshing.
@Mathias Bynens “According to the W3C,”:http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#alt the alt attribute should never be omitted, but instead defined as blank when the image provides no direct conversion to text.
I’m not sure why, when codifying common HTML conventions into HTML5, they didn’t just make the blank alt the default.
As long as the image is decorative, and the content covers what the image is about, then alt=”” is fine.
If it was used to perform a function, then you should never have the alt blank.
@Joseph Russell – Check out the Chromevox plugin (for Chrome of course).
I’m not sure I agree with this. Apart from just giving ammunition to those people who have a “can’t be bothered” approach to accessibility don’t alt attributes benefit more than screen readers? Say users who may be choosing which images they download, search engines finding pictures of the blogger. I’m sure there are more examples…
I personally would do something with the website links/twitter address on Faruk’s page, maybe something like:
and then put the .hidden off the page.
The screen reader would announce, “Twitter address kurafire”, instead of just “Kurafire”.
@Zeldman:
Actually what I meant was, isn’t it better to describe what the image is rather than not put anything at all? I agree with your example; stating the name three times is overkill. But screenreaders (and visitors with images turned off) will be notified of or shown an image area. They won’t know if it’s a photo or a diagram or what. That’s the only reason why I would suggest explaining what the image is, if not necessarily explicitly explaining it’s subject matter.
The alt text should never been empty if it adds to the content of the page.
In this example the image should come after the h1, as this is how an optimal document outline looks like. Then you’d have the h1 “Faruk Ateş” then an alternative text of “Portrait” (which is read as “Image: Portrait”) and then the paragraph.
Having an empty alternative text is OK in that case, but it would prevent a blind person to share the image, as it would be ignored.
Leaving out the alt attribute completely is no choice. A screenreader would read it as “Image: photo_126110_120_120_c1.jpg”. Nothing anyone would like to listen to. (Yes it is valid to leave it out, and yes that sucks.)
“The relevant techniques according to WCAG2 is can be found here.”:http://www.w3.org/WAI/WCAG20/quickref/#qr-text-equiv-all
This is a bit of #linkbait here, apologies for that but I found it relevant. Over on the A11Y Project, Bruce Lawson contributed a few more nuances when it comes to using the alt attribute: http://a11yproject.com/posts/alt-text/
There is some guidance on when to use an “empty alt attribute”:http://dev.w3.org/html5/alt-techniques/#secm3 in “HTML5: Techniques for providing useful text alternatives”:http://dev.w3.org/html5/alt-techniques/
If you use alt=” ” with an actual space there, NVDA, the open-source windows screen reader, still navigates to the image and simply reads: “graphic”, if you remove the space between the quotes NVDA will ignore the image completely. alt=” ” appears to cause JAWS latest and VoiceOver latest to ignore the image though. I never recommend using alt=” ” with a space, I always recommend alt=”” (null) with no space for decorative images that do not contain information and should be ignored by screen readers.
Since your author bio image is a linked image with no alt text, alt=” “, VoiceOver reads “link zeldman”. NVDA reads “graphic link”. JAWS seems to ignore your linked bio image completely.
doesn’t appear correct: “(The commenting engine will accept Textile markup.)” or I did something wrong…
Just like Brad Bice above, I thought the alternative text was meant to be a visual description of the image. _Portrait of Faruk Ateş in a grey suit, on a grey background._
The title attribute can then be “Faruk Ateş”
Daryl Fritz – there’s no need to add a title attribute to an image. Here’s a secreen-reading using blind friend of mine on title attributes: “Time to vent some steam about the TITLE attribute. This, almost more than any other item in the web author’s toolbox, seems to be misunderstood and overused…. Most often we see it on links and images, where it can confuse or even mask essential information. It can create issues on other elements, but for this article we’ll concentrate on the damage it can do to clear link text and images with good ALT attributes. Often creating classic examples of too much accessibility.”
Full blogpost: http://www.rnib.org.uk/professionals/webaccessibility/wacblog/Lists/Posts/Post.aspx?id=38
I too would use empty alt text. I contributed some tips to a11yproject http://a11yproject.com/posts/alt-text/
@Dean: “As long as the image is decorative …” it should not appear in the mark-up at all. alt=”” is not fine because the img element is not fine.
I don’t agree that “you should never have the alt blank”. What should be its value in this case?
bc.
I hate blogs without a comment preview function.
@Eric: That’s a problem of screenreader developers, not of Web site authors. Screenreaders should never read the image file name, IMHO.
alt=”” and no alt attribute should be the same. When there’s no need for an alternative text there should not be a need for an alt attribute. The HTML spec should not require an alt attribute on img elements.
A good analogy I heard when deciding on alt text: read the page content aloud (as if you were on a phone conversation). If you mention the image, it probably requires alt text.
It’s all about context.
This field of web accessibility is fascinating in that there are countless intricacies and finer points. And sometimes there are no clear cut answers. It is the web designer/developers responsibility to determine what is window dressing or eye candy or redundant.
As Eric Eggert said, a null alt attribute will be ignored completely by assistive technologies and will prevent a blind person to share the image. In addition in this case if anyone were to refer to “the portrait of
Hi Jeffery,
Recently, the team I work on settled on an internal ‘policy’ that suggests that adding a contextual prefix to alt text (not always, but when appropriate) has some significant value. (Note, part of the larger value is consistent use of this techniques – user expectations being a significant consideration; we want to be consistent as possible).
Consider for a minute the following 4 possible alt values for Faruk’s site:
alt=”Photo: Faruk Ateş”
alt=”Sketch: Faruk Ateş”
alt=”Caricature: Faruk Ateş”
alt=”Painting: Faruk Ateş”
…see where this is going? Without even seeing the image in question, *you* (as well as screen reader users) can at least get a sense of what that image of Faruk is likely to look like. Internally we came up with something of a standardized list of common image elements that we see frequently, and have now started to encourage the editor group to use this technique *when appropriate*. That list includes prefixes such as Chart (Pie Chart, Bar Chart, etc), Video (click on the image to launch the video), Signature, Map, and a few others.
NOTE: the one prefix to avoid ALWAYS is “Image”, as screen readers will already announce this to the end user whenever the reader encounters the < img> element. Also, the use of the full colon here is important – it adds a minute but perceptible pause when read by the screen reader. Putting it all together, and using the first example from above, the screen reader would announce to the end user: “image: Photo: Faruk Ateş” – clean, simple, accurate, and not too ‘wordy”
The key to alt text is in what could be described of as verbosity: while a picture is certainly worth a thousand words, many screen reader users don’t necessarily want those thousand words Every Single Time – ideally it is something that they can choose to hear (or not hear). This is far beyond a compliance issue, this is a User Experience issue. Using the above technique, we can succinctly inform the end use what the image is via a contextual prefix, and then tell them what the image is.
The alt attribute is intended to be an ‘alternative’ to the image, and not a description of the image (well, *rarely* a description) – we have other accessible solutions to achieve that: aria-describedby being one, and @longdes…. (not gonna go there).
Another way of thinking about alt text is to understand how it maps back to the native Accessibility APIs on the various operating systems: in a one-to-one mapping @alt is the “accessible name” of the object (as opposed to the “accessible description”), and so thinking of the alt text as a human friendly *name* for the image will also help guide you towards the appropriate value.
(See the ARIA mapping table to get a fuller idea of the various API values: http://www.w3.org/WAI/PF/aria-implementation/#mapping_role_table)
*****
To address the specific problem in your blog post, I agree that hearing “image:Faruk Ateş, heading level 1: Faruk Ateş, Faruk Ateş is a designer…” from a screen reader is also a poor user experience, but I think that it could be mitigated by a slight editorial change: adjust the @alt value using the suggested technique above, leave the h1 as is, but then perhaps start the first sentence with a different wording: “For the past 8 years, Faruk Ateş has been designing and delivering…” (or some-such): the point being that part of the solution is editorial, not code based.
@Gunnar: While I see what you mean, that’s not a thing about the purity of the spec. Missing alt attributes are an indication that the author didn’t care and left it out. By requiring the alt the author can explicitly state if the image is content or decorating. And stating something explicitly trumps code purity, imho.
We work with blind people on a regular basis, so here’s my tu’pence worth as recommended by our testers…
1) Do not use titles on links unless there is no text in the link, e.g. it’s just an image. Some screenreaders get confused, read one or other or read both. If you must use a title, make sure that it imparts more information than the text link (this often happens with document downloads).
2) The alt text should describe the image being portrayed. In other words, if Farouk is portrayed against some ghastly paisley wallpaper, then state it in the alt tag (not all blind people where born blind).
3) If the picture links to something else, then state that in the alt tag, not what the picture is about, e.g. “A link to Farouk’s profile.”
Simples.
DK
@Gunnar: You say decorative images shouldn’t be in the markup, but that’s not possible with responsive and fluid dimensions.
WebAIM also has some good guidelines on, and examples of, Alt text: http://webaim.org/techniques/alttext/. I think they would go with the empty alt attribute here. A good rule of thumb I read somewhere is if you were reading the page to someone over the phone—would describe the image?
If you use alt=” ” with an actual space there, NVDA, the open-source windows screen reader, still navigates to the image and simply reads: “graphic”, if you remove the space between the quotes NVDA will ignore the image completely. alt=” ” appears to cause JAWS latest and VoiceOver latest to ignore the image though. I never recommend using alt=” ” with a space, I always recommend alt=”” (null) with no space for decorative images that do not contain information and should be ignored by screen readers.
Since your author bio image is a linked image with no alt text, alt=” “, VoiceOver reads “link zeldman”. NVDA reads “graphic link”. JAWS seems to ignore your linked bio image completely.
@Tony Adams – If *I* were reading the page out over the phone, I would certainly indicate to the person on the other end that there was a photo of Faruk on the page – wouldn’t you? I wouldn’t “Describe” the image (“Faruk is wearing a black shirt with a white tie, the picture is taken with against a ghastly paisley backdrop”), but I would call out the fact that there was a picture of Faruk present – and then, *if* the person on the other end of the phone wanted me to describe it, I would then mention the tie…
This is indeed a good rule-of-thumb, but you need to think it through to the logical conclusion 🙂
John Foliot sez:
bq. alt=“Photo: Faruk Ateş”
alt=“Sketch: Faruk Ateş”
alt=“Caricature: Faruk Ateş”
alt=“Painting: Faruk Ateş”
I would wholeheartedly support your position if this were a piece discussion various photos of Faruk Ateş.
It isn’t.
Accessibility is about equivalency so I therefore take a moment to write alt text as if I were describing it to a friend. So far, it’s worked out pretty well.
I find it funny ALA tries to be so progressive and follow modern standards and yet you guys add a hack to support “older screen readers”. I say follow the standard, move forward. Remove that alt tag altogether, or leave it blank.
That was our feeling.
Paul J. Adam, that is excellent and very helpful feedback. Thank you! 🙂
Over the years I have struggled with this question myself quite a few times because it seems like repeating the same thing multiple times would create a bad user experience. When I used a solution similar to the one used here I used
alt=""(no space) just like Paul J Adam discussed. But I have never managed to find a solution that I was 100% happy with.Would it make any sense to use
aria-labelledby(oraria-describedby) to create an explicit relationship between the image and the text? But it does not seem quite right either because the bio is about the person and not the image.Maybe it is about context, if the bio mentions anything relating to the picture, like in Jeffrey’s case the color blue (i.e. blue beanie), then maybe the
imgalternate needs to be non-null and actually describe that the image is a photo of Jeffrey and he is wearing a blue beanie.@Der Caspers / @Jeffery Perhaps I wasn’t clear enough then; having a photo of Faruk with alt=”” is “WRONG” – it goes against best practices as well as the intent of that technique per the WCAG Success Criteria.
Read it: 1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose.
The photo is not “decorative” as it does have some contextual value to it. In other words, it is an important part of the page and its presentation. While I fully understand Jeffery’s concern over the user experience, this is the wrong solution to the problem: omitting the ALT text here is the wrong advice to be giving, as it is attempting to deliver a device-specific solution that at some levels is also patronizing – you are deciding that informing the blind user that there is an image of Faruk on the page isn’t worthwhile for them to know about, and so by using alt=”” you completely hide this fact from them. Really?
I’ve spent over a decade working with blind and low-vision users, and I’ve spent a lot of that time teaching, researching and talking to blind users, and so I was providing some feedback based on more than what I thought was a good solution. I was looking to offer the readers some possible better choices here (as well as maybe give the readers of this post some grist for their own mills) while at the same time keeping a positive ‘tone’ and also provide some real and researched reasoning on how and what @ALT text should be – if you bothered to get to the end of my initial response you would see how it was relevant to the Blog Title “On Alt Text”.
Sorry for trying to be helpful.
Dan Halpern, is what you’re describing more for the TITLE attribute? “ALT text” to me refers to “_alternate_ text,” rather than “descriptive text.” It’s the text you want read or seen if the picture can’t be read or seen. And if you don’t need text read or seen when an image doesn’t show up then feel safe leaving a value out of the ALT attribute. Or leaving that attribute out altogether, as the case may be…
John Foliot, what kind of alt text would go in for a picture of Faruk. Would it say, “This is a picture of Faruk that cannot be seen or displayed.”? Or, “This is a picture of Faruk.”?
It’s actually good to hear from somebody who has extensive experience in this area.
From some of the other discussion it seems that “alt text” is indeed no longer “alternate text,” but “essential text.” (And I’m not saying that “alternate” implies “nonessential” but that the general consensus seems to be that, if a value for the alt attribute is even included, that the value plugged in is seen as something other than “text served up as an alternative.”)
The fact that “alt” is short for “alternative” wasn’t even acknowledged in this post until comment #16.
Eric wrote: “By requiring the alt the author can explicitly state if the image is content or decorating.” The author already did — by using an img element which means the image _is_ content. Decoration should not be written into the mark-up but as backgrund image into the stylesheet.
That in mind, there’s no need to distinguish between alt=”” and no alt attribute.
Now one might argue if the HTML spec wouldn’t require alt attributes a validator would not tell when they’re missing. But I expect a huge overlap of authors who leave out alt attributes and authors who never use a validator anyway.
@ cmziebarth As I noted in my initial response, in this circumstance I would use alt=”Photo: Faruk Ateş”, which a screen reader would announce as “Image: Photo: Faruk Ateş” (others have suggested alt=”Portrait of Faruk Ateş”, which would be a good possible alternative as well).
I chose the prefix of Photo, as it best indicates the type of image being used for Faruk. If I were using this image:
!http://fc00.deviantart.net/fs40/f/2009/023/4/4/Barack_Obama_Caricature_by_heckthor.jpg(Caricature: Barack Obama)!
…then I would write alt=”Caricature: Barack Obama”. My goal is always to keep alt text as succinct and terse as possible, because I want to keep the verbosity of the screen reader’s ‘reading’ to a minimum. Adding a detailed description adds additional verbosity, and as a result subjects the non-sighted user to what amounts to a detailed examination of the picture, as opposed to an equivalent of a glance.
It is important to remember that “blind users” is not some monolithic group of users who all have the same needs, wants or web-surfing habits, any more than Mac Book Pro users are a monolithic group of web users. Users who have been blind from birth often tend to want the minimal-to-no ‘description’ of an image, as it tends to be an abstraction exercise that has little value to them – telling them that Faruk is wearing a red shirt and a yellow tie is meaningless to somebody who has never seen red or yellow. Conversely, a user who has lost their sight later in their life will know what red and yellow “means”, and will be able to assemble “in their minds eye” a rough idea of what his wardrobe looks like. For this reason, and on-balance however, I tend to stay to the minimalist side of things when using ALT text. (Besides, is his wardrobe the most important part of the image? No.)
As for why even mention that the image is there (i.e. add an @alt value, as opposed to alt=””), here too there are a few reasons. First, believe it or not, blind users might have a use for that image: perhaps they are creating a list of speakers they have seen at conferences, as part of their web site (OK, this is weak, but it’s late and I going quickly here), or they are searching on the web for a photo of Faruk to show their sighted friends – the point is, why shouldn’t they know that on the bio page of a person there is a photo included? “Because they can’t see it” is a horrible response, and is patronizing and demeaning at a very subconscious but yet real level. There are also SEO benefits to be had here as well, and there are still instances where some users will be accessing the web with images disabled, at which point the alt text will render (as opposed to a blank “box”). Finally, to be WCAG 2 compliant, that specification is pretty clear that only “decorative” images (curly braces, and/or other visual flourishes that should be, by rights, now added via CSS as background images) should take a null alt value. (As a side note here, if the image “does” have a contextual purpose, DON’T bury it in your CSS, as it is completely hidden to the non-sighted user. This is a trend i see more often these days, as developers are looking to use CSS sprites to accomplish things. It may have an efficiency of code-weight gain, but it has serious accessibility costs).
To me, ultimately, it is about treating your non-sighted users as visitors who access your content differently, but equally. I want to treat them fairly and on an even footing: “deciding” that they likely don’t want to know that an image is on the page is a serious decision to be taken – would you for example “not” include the image, and instead simply provide a link that read “click here to see a picture of Faruk”? I think not, and so treat your non-sighted guests with that same kind of respect: afford them the glance that all sighted users will make when the page first loads (and avoid going into too much detail, because few sighted users are going to study the image as thoroughly).
HTH
@Craig:
bq. You say decorative images shouldn’t be in the markup, but that’s not possible with responsive and fluid dimensions.
It is possible, actually. With the background-size property.
The answer to what-about-vintage-IE questions would be: progressive enhancement.
@John Foliot: We are familiar with this line of thinking and would certainly have used it if it applied here. But little purpose would be served, we thought, by alt text stating “Cropped low-res photo of author Faruk Ateş.” Or “Head shot of Faruk Ateş wearing a suit jacket.” (Who cares that he is wearing a suit jacket?) Or “Well-lighted, professionally shot photograph of the author, Faruk Ateş.” (This matters to a blind reader how?)
A GQ photo spread on Faruk Ateş is one thing. A small author head shot is another. You might as well complain that the avatar used in your comment does not contain descriptive alt text. (No offense.)
Distracting readers with irrelevant content takes away from the reading experience, it does not enhance it. An incidental image adds the slightest of enhancements to a sighted reader’s experience. Therefore it belongs on the page. But describing such an image to a blind reader, when doing so serves no purpose in advancing her understanding of the content, would merely distract that reader and take her out of the content experience!
Good user experience, not adherence to rules, is the highest design principle here.
Again, no offense and thanks for the conversation. I think it is an important one. And I respect your right to disagree. 🙂
@Tim Murtaugh: “My info is probably overdue for a refreshing.”
That’s what WCAG is for! They’ve already researched this and published best practices: http://www.w3.org/TR/WCAG20-TECHS/H67.html (“Although alt=” ” is also valid, alt=”” is recommended.”)
@Jeffrey Zeldman: “Markup is an art […]”
Amen!
@Alan Dalton: Thanks, we are investigating, and will switch if it is the best option. Appreciate the link! 🙂
P.S. In our new comment system, you can create links by writing standard HTML, the same way you would on any web page. Thusly (view source):
http://www.w3.org/TR/WCAG20-TECHS/H67.html
Bearing in mind the inconsistency between screen readers (some ignoring a null alt, some reading the filename) would it not be less confusing for blind or low-sighted readers to not include an image at all where a null alt attribute would be used, and for example include some element with a background-image set in CSS instead? This way it is still visible to sighted users for decoration, but provides no distraction for those using screen readers.
@Jeffrey Zeldman: That the avatars on this site don’t have alternate text is part of a larger problem. Quite a few large sites like Twitter for example don’t ask for alternate text when people are uploading images. This is a problem. Then when other applications access content using APIs, like the login service on this site, they end up with images without alternate text. Which led to a discussion (elsewhere) about that “generated content” can’t have alternate text so they need to use alt=”” to get valid pages anyway.
This is something that can be solved, when you login using Twitter the first time and it attempts to get your avatar image it should ask for alternate text for that image. A better solution would of course be if Twitter actually asked for this information and made it available using their API.
Almost all images on this page lack alternate text. If these images were presentational it would be a better solution to include the images using CSS. But they are not. Isn’t time that we start to design and structure our pages in such a way so that we avoid this situation where we feel like we need to exclude a group of users from the majority of the non-presentational images?
I appreciate that it is useful to analyse if something is relevant for a screen reader user, but as a screen reader user myself, I have to disagree with the argument in this blog post. If there is an image, it is always best to know what it is. In this case, if I am reviewing the resume of this person, I may want to know if they have included a photo of themselves or not. If this technique is used, I wouldn’t know this. If I really don’t want to listen to duplicate information, I can easily turn off reading graphics in my screen reader settings. This technique unfortunately takes that choice away from a screen reader and this is not very good in my opinion.
I agree with Kiran.
Why should the average sighted web dev decide what a differently abled visitor requires or wants?
ALT is not just for people who are blind, and your approach to providing appropriate text alternatives can be aided by thinking of other use cases. Here are some scenarios to consider:
Not all screen reader users are blind. They are also used by people with extremely low vision, often in conjunction with magnification software, and by people with certain cognitive conditions, such as dyslexia. For someone with low-vision, it is helpful to know what is truly just decorative versus something they would like to know. Like other sighted people, they may like to know what the author looks like, and deem it worthwhile to fire up the magnification. (And if no sighted person is interested, why include it?) People with cognitive issues are commonly aided by reinforcement, such as alternative text that would unambiguously identify that the picture is indeed of the author.
You should also consider “situational” blindness, where people are using VoiceOver on their iPhone, for instance, because the environmental conditions make visual interaction difficult.
Another large group is people without high-speed Internet access. As of last summer, approximately 19 million people in the US still have no broadband availability. And then there are the times/places when your cell coverage is weak, and therefore slow. The first thing I do when in dial-up land is disable images (and sometimes scripting, but that’s another matter) so I can actually get pages to load in a timely manner. When you do that, the browser displays the alternative text, and you can decide if it’s worth the time and effort to load that image.
I rarely disagree with Mr. Zeldman, but I do in this instance. The portraits of authors are content and should have meaningful (but brief) alternative text.
Kiran Kaja said:
Ah, but you are not reviewing a resume in this case, Kiran.
Yes, alt text should be used in many cases.
I’m arguing that alt text was inappropriate in this usage.
Telling me that alt text would be appropriate in a different use case (viewing a resume) doesn’t invalidate my contention that it should not be used in the present use case. Apples, oranges.
I am not telling readers never to use alt text. I am saying, as with any rule, it is always important to test that rule against the particular use case and decide what is best. That is what web and interaction designers do for a living. 🙂
Admittedly, the things we’re arguing here are rather petty when you consider the entire realm of accessibility. The difference between a profile photo having alt text or not (assuming the image content is also presented in text), and whether to use alt=”” (image is always ignored) or alt=” ” (the image may be identified without any relevant content) are minor. Neither would be considered failures of any accessibility standard, and it’s unlikely we’ll come to any universal consensus on these issues soon.
For what it’s worth, we (WebAIM) do not generally advocate including alternative text on most images when adjacent text fully presents the content thereof. A profile/avatar image or product photo with the person’s or product’s name adjacent to it simply causes repetition and overhead. While good arguments for including text have been stated, we believe and our extensive user testing has proven that the overhead of this duplication of content greatly outweighs any minor benefits. Screen reader users never want to be left out, but they quickly request alt=”” when such images all begin providing duplication of content.
Disclaimer: If the image is the only thing within a link, it MUST be given alternative text, even if repetitive.
As for alt=” “, I can think of no reason why this would ever provide any benefit over alt=””. Causing some screen readers to identify the presence of the image, but provide no content for it is problematic. Alt=”” is most appropriate for decorative images or images that have their content presented elsewhere.
Sarah Bourne asked:
This was answered in an earlier comment:
I fear that my example of a thoughtful decision about alt text in a particular design application is being taken out of context as a general rule. I am not saying, and would never say, “don’t use alt text” or “alt text is irrelevant” or “images are always irrelevant to blind folks” or any other such dogmantic nonsense. I’m saying a specific thing about a specific design decision, and I stand by it. While discussion is welcome and enlightening, I worry that some commenters haven’t read or understood the actual post, but are instead responding to a call to arms from a concerned citizen who has misunderstood my point in this post.
Hi Jeffery,
Thank you for un-sticking my comment from moderation but it now seems it is truncated. It read:
The problem here is that everyone does not have the same definition of "irrelevant content". Some users may want to know an image is on the page others may not. You have made the determination here that head shots are "irrelevant content". This in turn locks out the people that Sarah Bourne enumerated. However, I certainly agree that a long description for Faurk’s photo is not appropriate in the alt attribute. Personally I’d rewrite the page a bit so that an alt was not redundant and go with John’s suggestion. That way no users are left out.
Thank you for initiating this discussion.
There can be a lot of important, and potentially relevant, concise data in a bio photo–gender, race, age, ability (glasses, prosthetics)–and if it isn’t in the bio itself, should it be in the alt text.
As it’s presented for Faruk, a blind user has no idea how old Faruk is, but a sighted user can make a relatively accurate estimate. A sighted user can reinforce ethnic inferences, a blind user cannot.
This information may not be relevant, but it’s information being provided to one audience–intentionally or not–and arbitrarily withheld from another.
Kudos to everyone. Any discussion about accessibility, is good discussion.
@gguillotte:
Are you suggesting that we write alt text describing people’s ethnicity? Shudder.
@gguillotte:
Are you suggesting that we write alt text describing people’s ethnicity? Shudder.
gguillotte wrote at 12:35 pm on January 31, 2013
Frequently a primary short text alternative will suffice to make
an image accessible. However if the short text alternative does not provide a text equivalent for the image, a long text alternative can be used to supply supplemental
content via a secondary mechanism.
A secondary long text alternative can provide an equivalent experience and will give a user
choice in the amount of detail they wish to receive about an image.
Sighted users can glance at an image as they scan a web page (alt functionality), or
they can concentrate on an image (long description functionality). Blind users need to be able to do the same.
With your Faruk Ateş photo example, if you leave the image alt attribute blank or do not include it at all, would a screen reader read it as follows?
“Photo. Faruk Ateş. Faruk Ateş…”. Or is it ignored?
In passing, I think SEO “experts” are the worst abusers of the alt attribute.
Hi Jeffery,
Thanks for the opportunity to explore this issue in fuller detail. I would like to use a fair bit of your digital ink here to dive into this further, and I thank you in advance for indulging me the ability to do so.
bq. We are familiar with this line of thinking and would certainly have used it if it applied here. But little purpose would be served, we thought,…
I think that this is an important point to stop, and ask, did you back up your assumptions with any form of research? Did you ask any blind users their opinions here? I’m suggesting here that your assumptions, while well-meaning, arrived at a flawed conclusion *in context*. The key questions here are, what is the purpose of this page? Why am I adding a photo of Faruk to this page? You yourself state that this is “… a common bio. For instance, this bio of Faruk Ateş.” Thus the question becomes, is adding a head shot to a *biography page* important, or decorative?
bq. …by alt text stating “Cropped low-res photo of author Faruk Ateş.” Or “Head shot of Faruk Ateş wearing a suit jacket.” (Who cares that he is wearing a suit jacket?) Or “Well-lighted, professionally shot photograph of the author, Faruk Ateş.” (This matters to a blind reader how?)
I agree those alt examples are not useful, and in fact would likely be ‘intrusive’. This is why I originally suggested an alt value of “Photo: Faruk Ateş”. You are correct in suggesting that a complex description of the image serves little value in this context, but once again, the core question is, is there *any* importance on inserting a head shot in a bio page? Of course there is, or you would not have done so (especially given the latest “minimalist” design esthetic adoped at ALA).
Let me ask/state this another way: if the headshot image is so inconsequential, why not put it in the page as a CSS background image? (Could it be that perhaps a sighted user may want to copy and paste that image?) Would adding style =”display:none” to that image have any impact on the page for your sighted users? (If hiding it from the sighted user *would* have an impact – again, in context – why are you deliberately hiding it from non-sighted users?) I suggest again that seeking to craft a different experience for blind users (versus “everybody else”) has on the surface a noble sounding goal to it, but have you considered that you are actually marginalizing those very same users by taking a paternalistic view that the image has no value to them because they can’t see?
bq. A GQ photo spread on Faruk Ateş is one thing. A small author head shot is another. You might as well complain that the avatar used in your comment does not contain descriptive alt text. (No offense.)
None taken. But you’ve highlighted 3 different scenarios, and it is with one that we currently seem to be at odds. I’d like (for the benefit of other readers) to examine these 3 scenarios in a bit more detail. But before I do so, I’d like to revisit the Accessibility APIS of the various OSes, as having a basic understanding there will be valuable moving forward in the discussion.
These APIs all have different terminologies, but all provide some basic functionality that allows the systems to abstract “the intent” of any programmatic object from the GUI, so that alternative technologies can interact with the OS. (Remember, screen readers interact with more than just web browsers, they interact with every aspect of the OS.) Two key concepts related to this discussion are the properties of Accessible Name (or Label) and Accessible Description. Rightly or wrongly, @alt maps to the Accessible Name (which allows us to convey a human readable label of the image to the AAPIs), an important consideration to this discussion. In HTML4 the specified way of providing an Accessible Description was to use (my poor beleaguered) @longdesc. This is not the time or forum to go down that path, but with the introduction of ARIA, we also have other ways of expressing those 2 concepts: aria-label and aria-labelledby for the Accessible Name, and aria-describedby for the Accessible Description.
Set?
1. *The GQ photo spread*: in this scenario, yes, providing a more detailed description of the photo is critical to the non-sighted user’s experience and comprehension of the “complex image”. If we are to fully support the Accessibility APIs requirements, we will need to add both an Accessible Name here, as well as the Accessible Description (or: alt/aria-label/aria-labelledby AND longdesc/aria-describedby). Without prescribing a specific way of doing this, these would be the abstracted requirements for an image such as this.
(continued)
2. *the avatar used in your comment*: in this scenario, I think we can all mostly agree that the avatar lends minimal if any real value to the page content, and most non-sighted users I have spoken with fairly concur: we likely neither need an Accessible Name nor an Accessible Description in this use-case.
The Accessibility APIs all deal with this particular scenario in slightly different ways, but in ARIA we have aria-hidden=””. Due to historical reasons (and pre-ARIA), the screen readers all collected around the idea that the null alt value (alt=””) would define the same concept: “that the element is not visible or perceivable to any user as implemented by the author.” (On a twisty path, CSS visibility:hidden and/or display:none also delivers essentially the same end result to the Accessibility APIs).
Put another way, you could hide the avatar image in any of the following ways: < img alt="">, < img aria-hidden="true">, and (technically) < img > (although that isn’t going to help the sighted users either). One could also add the image as a CSS background image, at which point the image is completely removed from the DOM tree, and thus not exposed to the screen reader or Accessibility APIs.
Which brings us to:
3. *the author(bio) head shot*: in this scenario I (and others) have argued that there is some intrinsic value in informing the non-sighted user that there is an image on the page. I believe that in this case, the image is significantly more important than the avatar scenario, but also agree that it is not in the same class as Faruk’s GQ photo-shoot. This leads me to then argue that an Accessible Name is required, but likely not the Accessible Description. There is value in *labeling* the object as “this is a photo of Faruk”, but far less value in *describing* that object (“Well-lighted, professionally shot photograph of the author, Faruk Ateş.”)
It is based upon this reasoning then that I proposed to Jeffery that a) *this* image, in this scenario, *DOES* require an alt value, and/but that the alt value be nothing more than “Photo: Faruk Ateş”.
bq. Distracting readers with irrelevant content takes away from the reading experience, it does not enhance it.
Agreed. If this image, in this scenario, is so low value however as to be considered “irrelevant”, then why not just render it via CSS?
bq. An incidental image adds the slightest of enhancements to a sighted reader’s experience. Therefore it belongs on the page.
Aha, so this image *does* add some value, even if deemed “the slightest of enhancements”, at which point making the value judgement that non-sighted users don’t need or want that “slightest of enhancements” strays into the realm of paternalistic presumption. This is not to suggest any kind of maliciousness, but I ask one and all to ask themselves what if *I* was the one who was being singled out here for a “different” experience?
bq. But describing such an image to a blind reader, when doing so serves no purpose in advancing her understanding of the content, would merely distract that reader and take her out of the content experience!
Which brings us full circle: this is an assumption you have reached, but I wonder aloud how you tested this assumption before adopting it? Further, based upon the above, I’m not suggesting we need an Accessible Description, only an Accessible Name (label).
bq. Good user experience, not adherence to rules, is the highest design principle here.
Agreed, and I think very deeply (and ask constantly) about how and what the user-experience should be for non-sighted users in my job and role as a Web Accessibility Specialist. I am asking you to reconsider what the user-experience for the non-sighted user actually will be, here, on this page, a bio page that tells the end user about Faruk. Why shouldn’t we tell the non-sighted user that we also have a photo of Faruk available?
Sorry to take over your blog Jeffery, and I hope that this helps (or at least fosters more discussion).
Cheers!
I hope people will read John’s discussion with some care. I think it’s very clear and well-stated.
As a blind screen reader user who follows A List Apart specifically to learn about Web site development, I do want to know about what the site looks like. I don’t need a long description of someone’s photo, but I would find it valuable to know it’s there so that if I want more information about it, I have the choice to get it.
As I see it, this should all come back to defining the audiences that this site serves, such as via personas (at least some of whom would have had, I hope, a range of disabilities).
In other words, it seems to me that A List Apart should specifically consider who its blind audience may be, not to mention all of the other kinds of people who may find information in alt attributes helpful, such as those Sarah mentioned.
When I come here, I’m not skimming a mainstream magazine; I’m coming here to read about the Web and how it works. It seems to me that the site should showcase that. What if I want to show this site, as an example, during the Web accessibility trainings I do?
A List Apart sets a very visible example of best practices, so I thank you all for taking accessibility (of all kinds) seriously.
It might be redundant for screen readers, but this brevity hack is nothing less than data mutilation.
An image of the subject is content, not decoration. If it’s valuable information to the visual reader, then it’s relevant to the screen reader as well. I agree with the idea of mentioning the image type, e.g. Photo/Caricature/Illustration, as adding value for the time-suck it will be. There needs to be a balance between the fact that screen readers won’t be good at everything, ever, and the fact that we’re also presenting data.
In the year 2525, when this page is the definitive source of information on Faruk Ateş and patent trolls demand a day’s paycheck for every pixel rendered in a browser, that hole in the data is going to look awfully conspicuous. Should our jet-packed, Mars-dwelling reader fill in the blanks on her own, or can we at least drop a hint?
There are a lot of things that make the web great, but I think the best of them all is empathy.
Putting ourselves in each other’s shoes and thinking, how would I feel?
That very good intention is at the heart of this post.
“How would I feel hearing Faruk’s name being read three times in a row?”
(We may want to all just take a moment to thank Faruk himself for being the example in this exercise of empathy.)
It’s very understandable to assume that hearing anybody’s name being read three times in a row would be bothersome, and thus—since markup is indeed an art, not just an abstract set of rules—make the decision to omit the second mention of an author’s name.
The tricky part is how we know whether our empathy is well-placed.
I care a great deal about accessibility. I’m a solo web worker who works internally at an organization, so if I wonder how to handle a certain markup issue as it pertains to accessibility, I’m likely to search the web for articles, maybe ask a question on Twitter. I’ve seen a couple demonstrations of how a screen reader is used by people who are blind, but it would be difficult for me to directly ask the wide range of people who use screen readers how to handle a particular markup issue. Or to set up an accessibility study to examine one particular markup issue. I just don’t have those sorts of resources.
I rely upon expert advice that I have read on how to navigate through markup challenges. I would guess most web developers and designers with constrained resources do something similar.
It seems to me there are a few ways to respond when a questions arises, “How would somebody feel about this?”
1) “Here’s my guess as to how somebody feels.”
That guess may well be backed up by sound deductive reasoning or instinctive insights about how people work. Sometimes this will be right, sometimes it won’t.
2) “Here’s what somebody else said about how somebody feels.”
Researching expert articles or studies, hoping to find situations that resemble your own. Sometimes experts disagree, sometimes their situations differs from your own. Sometimes experts opinions may be based on direct research that is outdated or spot-on.
3) “Here’s what a number of people told me about how they feel, and here’s what I’ve observed personally.”
This is the essence of all usability testing and user experience research. Rather than trusting our instincts, getting people to give us direct feedback on our particular situation. The applicability of the feedback you receive is dependent on your sample size: one or two people are not likely to be representative of all use cases. But enough people weigh in, and you get the picture. Do enough work soliciting direct feedback, and you’re likely to become an expert who can to some degree serve as a proxy in answering the question “How would somebody feel about this?”
The trouble is that many of us just don’t have the resources for option three, or even to consult directly with an expert on our particular situation.
So while I certainly have empathy for those who use screen readers, and can think of how they might feel about hearing there is a picture of Faruk available on this page, I also have a great deal of empathy for those who worked on this redesign and did the best they could to think through how to handle that situation, even if they didn’t do direct research with screen reader users. Putting your work out there, your work that you’re proud of, and hearing back, “You’re doing it all wrong!” isn’t the easiest thing in the world.
Here’s my takeaway from this discussion. While I certainly understand the editorial decision made to use null alternative text in this situation, there may be several benefits to screen reader users provided by using a short caption:
1) Allows a screen reader user to make use of the image (assuming the image’s copyright allows this) in another context, such as creating a conference web page.
2) Allows a screen reader user to share the photo with somebody who might have a use for it. “This is a picture of Faruk. He’s a great guy. Say hi to him for me at the conference if you see him!”
3) Allows search engines to find images of Faruk.
4) Allows users with low vision to know there is an image and increase screen magnification in order to better see the image.
5) Assists users with cognitive issues through reinforcement.
6) Lets sighted users who may be using a VoiceOver service (while driving) know there is an image they can refer back to at a later time.
7) Allows users with low bandwidth to know the purpose of the photo if it is unable to load or if they choose not to load images.
To me, that’s a decent list of situations where having null alternative text may be an issue, and personally I will be a lot more careful about providing short captions even in situations where my initial reaction might be to assume that an image is just decorative and doesn’t need an alternative.
The creators of this site are, of course, welcome to their own judgments on the matter. They’ve thought the issue through and came to their own conclusion based on their particular situation.
Bottom line, let’s all just keep exercising empathy, both for the users of our sites, and for each other. The web is a truly marvelous place, but it gets that way through the hard work of all of us, and we owe it to each other to put ourselves in each other’s shoes as much as we can.
As an accessibility expert I would recommend that you set the alt as minimal as possible for both your headshot and the bio headshot image.
I recommend you say alt=”Author’s Headshot” for both headshot images.
It’s obviously not a purely decorative image, otherwise it would be some random pattern or squiggles. But it’s not, it is the headshot photo of the author.
The reason a blind user might need to know that it’s the author’s headshot is if they’d like to use that image in some other form of presentation like a PPT talking about experts in the web dev field. If you set the alt to have screen readers ignore the image, then it is of no use to them. They would have to then ask a sighted friend for help and say “Hey can you find me a pic of Zeldman? I can’t find any on his site :(”
I don’t think you need to say alt=”Jeffery Zeldman’s Headshot” or alt=”Faruk Ateş’ Headshot” unless you want to. By just saying alt=”Author’s Headshot” you can use the same template over again and never have to change the alt. The screen reader user can easily determine who the author of the page is and know that this must be their headshot and now if you’re speaking at an accessibility conference organized by a blind user they’d have no trouble slapping your headshot in the conference website.
I do not agree that it’s a purely decorative image. I think it needs a minimal alt attribute.
As a web accessibility specialist, I totally agree with John. The Alt text should be “Photo: Faruk Ateş” so that non-sighted user will be able to know that there is a photo of Faruk Ates on this page. I’d like to ask you the same question. “Why shouldn’t we tell the non-sighted user that we also have a photo of Faruk available?”
Out of curiosity, how does that information help the non-sighted user?
If the non-sighted user has the right to know that there is a photo on the page (and I don’t deny that she does), doesn’t she also have the right to know something about the page’s design and layout?
Does the non-sighted user need to know that the page is responsive?
Should she be told something about the flavor of the design? She has the same human right as anyone else to know that the headline is set in ITC Franklin Gothic and is considerably larger and bolder than the headlines on many other websites.
If she is reading an A List Apart article, she has the right to know that it is adorned by a Kevin Cornell illustration which comments wittily on the article’s content in a visual language known only by Kevin. She has the right to respond to and interpret Kevin’s strange and unusual artwork. Yet I defy any writer to explain in an alt text the flavor of Kevin’s work, what is happening in this particular illustration, how this illustration’s content relates to other illustrations by Kevin throughout the magazine, and so on.
One can write, “Illustration by Kevin Cornell,” and we do write that. We present that information in HTML, where anyone, sighted or not, can read it. That is the function of an alt text but that function can be carried out just as effectively by other text on the page.
We use alt text where it makes sense to do so. We sometimes skip alt text if we can put the same text in front of the reader in another place, where it is accessible to everyone, sighted or non-sighted. These are design decisions. They are not offenses against anyone’s human rights. We think constantly about our readers, all of our readers, and the best ways to enhance and deepen their experience and engagement with our content.
There are some elements of the A List Apart reading experience, such as the experience of examining Kevin Cornell’s strange and wonderful drawings, or the experience of reading these particular words in these particular fonts at these particular sizes in these particular colors, that cannot usefully be translated for folks who cannot see.
This is true of the content of every website ever created. Alt text and other accessibility techniques cannot replace purely visual experiences.
I content that “photo of the author” would provide only banal and useless information to an unsighted user, unless that photo by its unique composition and other characteristics added significantly to the content of the page. The reader can enjoy the article without being interrupted to hear about a photo she cannot see in the same way that she can enjoy and benefit fully from an article without being interrupted to be told about some other small decorative flourish, such as the wreath on the comment sign-in button.
Peace.
The system just ate my comment. :-/ So now in short:
Jeffrey, all the use cases of an alternative text are shown in comment 71: http://alistapart.com/comments/on-alt-text#333859
I don’t know why we’re now discussing every alternative text on every website and every use case instead just keeping our eye on the example in question.
As with all other things in the web stack, there are sometimes different right solutions. I’d do it differently than John who does it differently than Bruce who does it differently than you. That’s fine. And if you’d ask screen reader users, they may be fine with every solution. We have our preferences in a similar manner when we talk about document outlines, microformats, new HTML5 elements and some even argue about semicolons in JavaScript.
It is okay to have different opinions.
We’re over-complicating this.
I recommend Dey Alexander’s decision tree for text alternatives for images as the take-away from this discussion.
(It follows WCAG’s “Non-text Content” success criterion.)
Hi Jeffrey
bq. Out of curiosity, how does that information help the non-sighted user?
As I’ve tried to explain, giving the non-sighted user a detailed description of Faruk here does little service (Accessible Description). *Advising* them that there is a picture of Faruk on the page has value (Accessible Name), and as Jennifer (a blind user who comes to ALA) noted, if she wants to know more about Faruk, she can ask: she can ask *you*, she can ask her friend(s), she can ask whomever she can, “Excuse me, there is a picture on this web page – can you describe to me what Faruk looks like?” The point is, *she knows that there is a picture here of Faruk*; it’s not been deliberately kept from her for fear that it _hurts_ her reading experience: “poor Jennifer, she’s blind”… I know that is not your intent, but in many ways it is coming off like that. Blind people appreciate thoughtful design, they really do, but they don’t want to be ‘sheltered’, they want to be treated as equally as everyone else. Telling them that there is a photo of the author here, without going into a whole lot of detail or fuss, is thoughtful – that’s all I’m suggesting
bq. If the non-sighted user has the right to know that there is a photo on the page (and I don’t deny that she does), doesn’t she also have the right to know something about the page’s design and layout?
Good question. She does, and that’s why we have ARIA constructs such as role=”header”, role=”search”, role=”main”, etc. Those attributes define the layout – in a structural way – that is extremely useful to the blind user. An experienced screen reader can quickly navigate around the page using these constructs (as well as headings), as opposed to consuming the content in a linear fashion (based on source-code), which is the default way that they would do so. As screen readers continue to update and evolve, they will soon be able to also make use of the HTML5 landmark elements, like header, nav, footer (and, thanks to Steve Faulkner 🙂 ) main. These *landmark* elements are so named for a reason (and it has more to do than just for CSS styling).
bq. Does the non-sighted user need to know that the page is responsive?
Not in the way you are using ‘responsive’ here: no.
If/when authors choose to go the other route however (mobile version versus desktop version, via a switcher) then that is *very* useful information: there is a very strong chance that the mobile version will be more accessible (sadly), as a lot of the cruft that has been trimmed there is also auditory cruft for the screen reader too ().
bq. Should she be told something about the flavor of the design?
Don’t confuse layout comprehension with visual styling. Jeffrey, for over a decade I’ve had to answer the charge “accessible websites = boring websites”, and that is simply not true. Good visual design is important (critical?!) to a web site development. A well designed site (from architecture down to color choices) can have impacts on numerous groups of PWD (Persons With Disabilities) that would take a whole book to document, and no Accessibility Specialist worth their salt would ever suggest otherwise. But it is important to keep all of that in context: blind users don’t *need to know* every detail of the visual layout (although, for a specialty site such as ALA, as Jennifer noted, perhaps a page that did go through the ‘artistic’ exercise of documenting general design guidelines might prove useful for a certain segment of the audience: why not? I mean, you tell readers of A Book Apart what typeset you use in the Colophon…).
bq. She has the same human right as anyone else to know that the headline is set in ITC Franklin Gothic and is considerably larger and bolder than the headlines on many other websites.
Sort of. She likely doesn’t need to know that it is ITC Franklin Gothic on every page (however, see my previous comment), or that it has been styled “jumbo-font”: this is why we separate style from structure (as you long ago taught so many) – this is another reason why we use standards. What the blind user *does need to know* is that the headline is a headline (h1 or h2) and not just some div with class=”headline”.
bq. I contend that “photo of the author” would provide only banal and useless information to an unsighted user, unless that photo by its unique composition and other characteristics added significantly to the content of the page.
Well, given that it is pretty much a single-use photo (remember, we’re talking about a BIO page here; the photo is unique in that it is of “Faruk”, and not ‘generic author’), *I* contend that you should be following your own advise, as this photo *is* unique. It comes down to how significant that photo is – *in context* – on a biography page, and that boils down to opinion.
(continued)
At any rate Jeffrey, it has not been my intent to show up and yell “You’re doing it all wrong!” (even though, in my opinion, you *are* missing something pretty important here). Instead, I’ve tried to walk you (and others) through the thought process with a different perspective than the one you first arrived at, to show how and why I disagree with your conclusions, and to back that up with research and reasoning and pointers to the relevant specifications (etc.). As others have noted, design is also opinion, and you made a conscious decision here (as opposed to a sloppy mistake) and that’s cool. I think however that sadly at this point I’m not going to change your mind, and so all I can hope is that the readers have followed along and absorbed some of the alternative viewpoint, so that when *they* have to make a similar decision, they will do so from a point of actual reasoned thought, and not just because “they saw it on ALA”.
bq. The more you know…
Thanks Jeffrey – peace!
There was much less contention over your choice to use blue for your links! 😉
past midnight here, but this is core, so i’ve read most/some/bits of it 😉
Jeffrey: I’ve not seen an answer to John’s main issue here: the null alt is actively denying the existence of the image to screenreader users. Isn’t it?
@John Foliot: You make some good arguments, but I would like to discuss more on some of your point if I may?
You “ask” if the picture in the Bio is either important or decorative. I would stipulate that it depends on what the bio is used for and who is reading the bio. Most of the time, a picture in a bio is just there to put a face to the person so it makes the page more personal. Is that important? Only from a psychological point of view. Is it decorative? Not really since it adds a certain type of information, but not information we could do without. The bio would not be any less informative without it. So basically, the picture adds a visual reference. Is that something a non-sighted person needs to know? While I agree he/she has a right to know it, I think that the right to get the same information with the same quality is more important than the right to be able to know what is on the page, esp. if it adds no value, but perhaps diminishes the quality of the information.
I am a strong proponent of the way HTML5 suggets we use alt. That is, we use alt as text that replaces the picture. I usually do it like so: I write a story, then I choose which line(s) of text I could replace with a picturte (for sighted users) and put that line of text in the alt-attribute. Obviously, the line of text should accurately describe the picture. For me, the alt-text is simply put, the text I would have included if I had not put in a picture. I would love to hear your thoughts on this?
I think John will be writing more on this topic in a future ALA feature article.
Yuvalik asks / said:
bq. Most of the time, a picture in a bio is just there to put a face to the person so it makes the page more personal. Is that important? Only from a psychological point of view.
Are you then suggesting that “from a psychological point of view” deliberately hiding the fact that an image is on the page is a better option for blind people? Why? I’m not trying to be antagonistic, but what value is there in denying some users the same information that you provide others? Why do you feel that blind users DON’T want to know that the author’s image is there?
bq. Is it decorative? Not really since it adds a certain type of information, but not information we could do without. The bio would not be any less informative without it.
You’ve answered it yourself: *”…it adds a certain type of information…”* A key point I’ve striven to make is that it should not be the author’s decision on what a blind user needs or wants – it should be the blind user’s choice.
bq. So basically, the picture adds a visual reference. Is that something a non-sighted person needs to know? While I agree he/she has a right to know it, I think that the right to get the same information with the same quality is more important than the right to be able to know what is on the page, esp. if it adds no value, but perhaps diminishes the quality of the information.
Perhaps you are not fully understanding what happens when you apply alt=”” to an image. It completely hides it from the screen reader user, in essentially the way that CSS @display:none;@ hides the content from the GUI (Graphical User Interface). If you agree that the user *”…has a right to know…”* then by hiding it you are actively removing that right. You are becoming the arbitrator of what is “quality” to the non-sighted users, and dismissing their ability to make that judgement themselves.
It is important to understand that all but the most novice of screen reader users (and that novice group is, fora large part, sighted developers who use a screen reader for “testing”, but never more than that), those daily screen readers know very well how to use those tools, at an expert level. It is trivial to silence a screen reader with a simple key-stroke, it is simple to skip over things, and screen reader’s have the ability to adjust what is known as the ‘verbosity level’ of these tools to meet their individual needs.
While well meaning, you do these users no favor by presuming to understand what they want from a user-experience, and from my research and discussions with a large number of blind users over more than a decade I can say with a fair amount of certainty that what they want is to be treated equally, not “specially”. Be sensitive to their needs, yes, but don’t presume that they are helpless or unable to take from your content what they need and want, and at the same time safely discard what they don’t want or don’t need.
As I’ve previously stated, this comes down to context: but as at least one non-sighted user has mentioned on this list, in this context, they want to know if there is a bio photo on the page. They don’t need to know what color shirt the author is wearing, nor whether the photo is taken against a “ghastly paisley backdrop” – everyone agrees that this adds nothing of value – but by the same token they *DO* want to know that the photo is there. At this time it comes down to a matter of faith: either you believe that I know what I am talking about here (and that I *_have_* listened and talked to blind users), or I don’t, and that your opinion and analysis differs from mine. And ultimately, that’s cool.
One last thought…
bq. I usually do it like so: I write a story, then I choose which line(s) of text I could replace with a picture (for sighted users) and put that line of text in the alt-attribute. Obviously, the line of text should accurately describe the picture. For me, the alt-text is simply put, the text I would have included if I had not put in a picture.
Let’s do a simple thought exercise: you are sketching out a wire-frame for your “Bio Page” – you’re going old-school and actually have a sketch pad and pencil. As you sketch, you draw a square, approximately 2” X 3” in the top left corner. As you are presenting the wire-frame to the client, they ask “What’s this box up here for?” – and so you quickly jot in “author’s photo”.
Later on, you are coding up the page, and using your own process outlined above, you “…choose which line(s) of text I could replace with a picture (for sighted users) and put that line of text in the alt-attribute…”
This leaves you with 2 options: alt=“author’s photo” or (”…text should accurately describe the picture…”) alt=“Photo: Faruk Ateş”.
Peace!
I don’t feel particularly qualified to speak out on the merits of the arguments and counter-arguments, but, I feel compelled to point out something I haven’t seen addressed:
The ALA team seems to be composed of people with sight, as do most of the usability experts in this discussion.
However, three (two? I may have mis-counted) people have commented to say that, as individuals without sight, they think the authors image should have an alt tag.
Personally, I think that trumps any well-worded argument, rhetorical position, or theoretical discussion. People without sight are speaking up and actually telling you what they prefer, and that matters more than a standard, a theory, or a concept.
Apologies if I am speaking out of turn or incorrectly.
@John Foliot: I’ll start with the last part of your reply:
I would go for : alt=”Faruk Ateş is a 34 year old male developer.” Would that be wrong?
The user is told it is an image (by the software) and the alt-text describes what is in the picture without becoming either too verbose or distracting the user from the rest of the story.
As for your other argument. I am ambiguous about that. I have no doubt non-visual users claim to want to know there is an image. And they probably have learnt to deal with all that “white noise”. The same as visual user deal with “white noise” in the form of pull-quotes and animations. And “white noise” has obvious advantages from a designers (and sometimes marketeers) point of view. What I have problems with is adding “white noise” that serves no other purpose than the claim of “rights”. Where is the line drawn? If I choose that a certain image is presentational (but still adds to visual information) and place it in CSS, it is also hidden from screenreaders. Am I then obliged to put in a footnote to describe the picture for screenreaders?
Look, I have no problems adding for example something like alt=”graph showing the relationship as described in the text.” if that makes people happy. But factually I do not understand what the value would be from the informational point of view. I would only do it not to discriminate? Don’t get me wrong, I do not mean this in a negative way, I am just trying to understand the reasoning behind it, since I feel (perhaps wrongly) that the demand for non-informational alt-text is based more on equal rights than it is on actual usability? Again, I am just asking because I wnat to understand, not to criticise.
The point is, I sometimes put text in my pages to help screenreader users which I hide from visual browsers. (like adding extra heading for easier navigation, or text to explain what will happen when pressing a button, since it might not be intuitive without the visual aids). Do sighted people have a right to know about that? Yes, should they? No, because for them it would only add an extra layer of complexity. Designing is more than just presenting information, it is about making things intuitive and user-friendly. I THINK (but perhaps I am wrong, so please correct me) that adding certain types of information to specific users CAN make things less user-friendly. It has nothing to do with assuming what someone needs or wants, but basing it on what might work best. (In the end, the website is there to make money for its owner, and that is the main objective of the design, to make sure the user performs the task to reach that goal as easy and fast as possible).
Continued: The term “make money” in that last sentence should read “reach a goal”.
If I may explain my view some more? Suppose you have a building and you put in a ramp for people in wheelchairs. The goal of that is so they can enter and exit the building without problems. Should they be told where the stairs are? It does not help them in any way entering or exiting the building. Do they have a right to know where the stairs are? Obviously. And knowing it might come in handy if someone asks them where the stairs are. So they are free to explore the building finding out where the stairs are so they have that information if they ever need it.
The question now is SHOULD I give them the information just in case they need it? I think it depends on the situation. If adding that information makes the required information (location of ramp) less obvious, I should probably not. If it doesn’t then I should. The “art” here is to be able to determine when information becomes overloaded. This is -up to a point- an individual issue, but in webpage design it is based on a general target-audience . We cannot cater for each individual individually so we make choices based on data and measurements. And I concede that regarding screenreader users, the data and measurements are fragmented at best, so we are (no pun intended) in the dark on some of the issues. So we can only base it on common sense (would adding this information add to reaching the required goal easier or faster). If the answer is no, then why add it? If the answer to that is: “because they might need it for something else” then we should first ask the opposite question: “Would adding it make reaching the goal more difficult?” If yes, then we should still NOT add it.
Not wanting to re-open old wounds, but advice I added today to the HTML spec seems relevant: Images that enhance the themes or subject matter of the page content (second code example).