The A List Apart Blog Presents:

On Alt Text

Article Continues Below

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…

87 Reader Comments

  1. @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?

  2. 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.

  3. 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.

  4. Kiran Kaja said:

    If I am reviewing the resume of this person, I may want to know if they have included a photo of themselves or not.

    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. 🙂

  5. 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.

  6. Sarah Bourne asked:

    And if no sighted person is interested, why include it?

    This was answered in an earlier comment:

    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!

    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.

  7. Hi Jeffery,

    Thank you for un-sticking my comment from moderation but it now seems it is truncated. It read:

    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/developer’s 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 Faurk" a person using assistive technology would not know what he or she was referring to. In contrast The Paciello Group uses staff member’s names as alt text on their staff photos after an h2 that contains the same staff member’s name. Assistive technology users will know that a image exists for each person.

    With that said, if the image isn’t providing any content or understanding of the context, then its alt text should be empty. I certainly agree with you that distracting readers with irrelevant content can take away from the reading experience.

    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.

  8. 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.

  9. @gguillotte:

    A sighted user can reinforce ethnic inferences, a blind user cannot.

    Are you suggesting that we write alt text describing people’s ethnicity? Shudder.

  10. @gguillotte:

    A sighted user can reinforce ethnic inferences, a blind user cannot.

    Are you suggesting that we write alt text describing people’s ethnicity? Shudder.

  11. gguillotte wrote at 12:35 pm on January 31, 2013

    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.

    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.

  12. 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?

  13. 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)

  14. 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!

  15. 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.

  16. 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?

  17. 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.

  18. 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.

  19. 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.

  20. 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?”

  21. 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.

  22. 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.

  23. 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)

  24. 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!

  25. 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?

  26. @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?

  27. 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!

  28. 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.

  29. @John Foliot: I’ll start with the last part of your reply:

    This leaves you with 2 options: alt=“author’s photo” or (”…text should accurately describe the picture…”) alt=“Photo: Faruk Ateş”.

    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).

  30. 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.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA

I am a creative.

A List Apart founder and web design OG Zeldman ponders the moments of inspiration, the hours of plodding, and the ultimate mystery at the heart of a creative career.
Career

Discover more from A List Apart

Subscribe now to keep reading and get access to the full archive.

Continue reading