Problems with the CSS background-image property(nystudio107.com)
nystudio107.com
Problems with the CSS background-image property
https://nystudio107.com/blog/the-css-background-image-property-as-an-anti-pattern
86 comments
Author here. What advice is "bad" in your estimation?
As for not following my own advice, that's not quite right. I'm using picture and img tags rather than div's with CSS background-image, which is the main thrust of the article.
I'm also using srcset for performance, and webp as a progressive enhancement for browsers that support it.
The only thing I'm not doing is using the new loading="lazy" because the website was creating long before the article.
As for not following my own advice, that's not quite right. I'm using picture and img tags rather than div's with CSS background-image, which is the main thrust of the article.
I'm also using srcset for performance, and webp as a progressive enhancement for browsers that support it.
The only thing I'm not doing is using the new loading="lazy" because the website was creating long before the article.
Given that all the images in the article are purely decorative, why you using picture and img tags rather than CSS background-image? You're also supplying alt attributes, so someone with a screen reader will hear a random "Bad boy doggo" in the middle of an article about HTML and CSS.
Agreed; if the images are purely decorative (some are, some are not) then it should have an empty `alt=""` to have screen readers skip them.
But I would still want to use an actual picture element with srcset & source attributes/tags for the reasons mentioned in the article.
But I would still want to use an actual picture element with srcset & source attributes/tags for the reasons mentioned in the article.
Efficiency/SEO sure but what makes this bad for accessibility? It's a standard <img> with alt text, does it matter for accessibility where the final pixel data comes from?
In case you are using a browser without JavaScript or have disabled JavaScript, or are using some customizations which the script on the webpage is not compatible with, then using a script to load the images can be bad for accessibility. (There is a legitimate reason to do so, but it is unfortunately used for many cases when it is not a good reason. If the width and height are hard-coded, then when the images should be loaded is possible to implement in the browser, subject to user settings, without needing a script on the web page.)
The article criticizes the abuse of background-image as a cheapass replacement for the img or picture tags that should be used for "content images".
It's not a controversial point of view: background-image has always been intended to be purely ornamental (for cases in which background-color doesn't look good enough) and there's no reason to worry about "semantic" features like alt text (a blind or text-only user doesn't care for how the page background is painted).
What perverted line of thought led to the apparently widespread abuse of background-image for content? CSS sprites, as suggested in other comments, are a significant hack that might have set an example but true content (rather than icons) in background-image is on a different level and requires additional explanation.
It's not a controversial point of view: background-image has always been intended to be purely ornamental (for cases in which background-color doesn't look good enough) and there's no reason to worry about "semantic" features like alt text (a blind or text-only user doesn't care for how the page background is painted).
What perverted line of thought led to the apparently widespread abuse of background-image for content? CSS sprites, as suggested in other comments, are a significant hack that might have set an example but true content (rather than icons) in background-image is on a different level and requires additional explanation.
I would suspect the main reasons are the possibility to format images are greater for background-image than img. Functionality like background-size cover or contain in a background image are difficult to mimic with an img tag.
But these features are meant for ornamental images, which should fit their container instead of being displayed "naturally". Stretching or cropping content images (instead of scaling and padding them, which is equally easy to do with proper and improper markup) is intrinsically inappropriate, not something worth doing.
I disagree. I would say cropping images is essential to be able to use images in responsive designs. It is obviously possible to make websites where images have the same aspect ratio on all devices, but in reality you dont always have the same people in charge of design as implementation.
In a responsive design, an image can be displayed with its proper aspect ratio, cropped as the author saw fit. It can be scaled to fill the available space horizontally or vertically, and it can be optionally optimized with a picture tag instead of a img tag to load a lightweight version if the available space is small.
Practical example: a group photo of 15 people smiling at the camera on the official page of some event. You adjust colour, you rotate the picture to get a horizontal horizon, you crop different amounts of excess background on each of the four sides. Then would you like "responsive" tricks to automatically slice away their feet because the screen isn't tall enough? Maybe their heads or a bit of both? Or should they be stretched instead, to disturbing squat proportions?
What kind of pictures look better deformed or mutilated than, at worst, unobtrusively letterboxed?
Practical example: a group photo of 15 people smiling at the camera on the official page of some event. You adjust colour, you rotate the picture to get a horizontal horizon, you crop different amounts of excess background on each of the four sides. Then would you like "responsive" tricks to automatically slice away their feet because the screen isn't tall enough? Maybe their heads or a bit of both? Or should they be stretched instead, to disturbing squat proportions?
What kind of pictures look better deformed or mutilated than, at worst, unobtrusively letterboxed?
As i said before im not disputing that it is possible to make responsive design keep same aspect ratio always. Im just pointing out that in reality you can not control all parts of your work. Design as i said can be done by people you have no influence over. And they might have very relevant reasons for making it the way they do.
Obviously the ideal situation isnt to crop images, but if the people using the system is aware they can select images that do not have esential information in the edges.
Obviously the ideal situation isnt to crop images, but if the people using the system is aware they can select images that do not have esential information in the edges.
`img` tags are (or partially were, with the recent introduction of the object-fit property) significantly harder to properly style and position. Contrary to your argument, achieving certain layouts with `img` tags required significant style hacks, while using `div`s with with a background-image has always been straightforward.
One explanation is that it's more difficult for non technical users to copy the image or url. Which worries many publishers. Eg people using their images/content without consent. DRM is a thing.
Both are just a right click -> inspect element away, I don't think anybody who knows how it works would advocate that.
"...background-image has always been intended to be purely ornamental..." That works for purely ornamental images, especially if the browser includes the ability to disable the background-image command (I wrote a document with ideas how to make a better web browser program, and one of the ideas is "meta-CSS", which is capable of doing this; the privileged CSS priority settings that I wrote about would also be capable of it; and you can also use both together if wanted).
It's largely used for large/fullscreen hero images on a page header with text overlaid. The easiest way to ensure required portions of the image are visible and the image always fills the container, and the text placement is exact, was background image. It's a problem we can now solve in multiple ways, with object fit and also with CSS Grid. But there's some inertia on the old background image technique; it's long established and will take time to turn around.
Author here. Yep, this is exactly my point! Don't use CSS background-image for "content images". There are significant downsides for doing so.
[deleted]
There are a number of people on this thread suggesting that the arguments in this article are fairly weak. That may be the case for some (or most) of them, but the accessibility concerns are right on point.
I work in digital accessibility and by using CSS background images as actual inline content, you're purposefully choosing a technique which does not have a well-understood accessible alternative. Which is fine, if you are one of the people who understand that alternatives do exist and how to use them. My experience suggests to me that the majority of web devs must not be in that category.
I thank the author of the article if including this concern helps just one developer or designer make more accessible images.
I work in digital accessibility and by using CSS background images as actual inline content, you're purposefully choosing a technique which does not have a well-understood accessible alternative. Which is fine, if you are one of the people who understand that alternatives do exist and how to use them. My experience suggests to me that the majority of web devs must not be in that category.
I thank the author of the article if including this concern helps just one developer or designer make more accessible images.
What the other people are saying is that images meant as content shouldn't be implemented through background-image.
Perhaps the article makes it appear that there is something wrong with background-image - there's not. It's just the masses of devs (and I'm guilty of this, too) using it in the place of an <img>. Background-image, in the same vane as background-color, doesn't need any accessibility.
Perhaps the article makes it appear that there is something wrong with background-image - there's not. It's just the masses of devs (and I'm guilty of this, too) using it in the place of an <img>. Background-image, in the same vane as background-color, doesn't need any accessibility.
<picture> isn't supported by IE 11 so for the moment this isnt really an option for us that need to support people with legacy browsers.
For those with a strong desire to use `<picture>` but also want to support legacy browsers, there's (almost) always a polyfill.
In this case: https://scottjehl.github.io/picturefill/
In this case: https://scottjehl.github.io/picturefill/
Isn’t it why you still put an img element in it ? Or am I mistaking ?
True, of course then you will have to deal with the formating problems that made you choose background-image over img in the first place. Though concidering the small numbers still using IE 11 that might be acceptable.
Would someone mind explaining what "semantics" a "picture" has that an "image" doesn't have (I'm not too familiar with semantic HTML)? It seems kind of bizarre that the img tag couldn't do both jobs.
An <img> is a tag that finds space to fit an actual grid of pixels.
A <picture> is a responsive-aware tag that can several <source> of actual images (of different sizes), as well as an actual <img> for legacy browsers to still be able to render something.
The <picture> element was standardized with HTML5 so the browser can figure out what <source> is best for its resolution, network speed/cost...
This way mobile phones don't have to download fancy 4K backgrounds, and we don't have to use Javascript because it's part of the HTML spec.
A <picture> is a responsive-aware tag that can several <source> of actual images (of different sizes), as well as an actual <img> for legacy browsers to still be able to render something.
The <picture> element was standardized with HTML5 so the browser can figure out what <source> is best for its resolution, network speed/cost...
This way mobile phones don't have to download fancy 4K backgrounds, and we don't have to use Javascript because it's part of the HTML spec.
Can anyone think of any evidence to back up the claim a third of google searches are for images?
It's wildly important for e-commerce.
I personally will use google image search if I'm looking for a particular instance of something generic (like replacing no-name chinese electronics)
The main source seems to be Jumpshot 2017 clickstream data, these posts on Moz are within 2 days of each other, the first is cited for the "a third" quote in TFA:
https://moz.com/blog/seo-photos-visuals-graphics-whiteboard-...
https://moz.com/blog/state-of-searcher-behavior-revealed
But "a third" seems a bit misleading as the big pie chart in the second only shows 26% (closer to a quarter). From the bars in the middle of https://sparktoro.com/blog/2018-search-market-share-myths-vs... (also Jumpshot data) we can see that Google Images has been steadily decreasing in share, it might indeed have been a third in 2010-2014 but today is probably below 20%.
Then there's this Quora answer from 2010, it has a 1:5.5 ratio of images to search from Alexa, i.e 15%: https://www.quora.com/What-is-the-ratio-of-Google-Image-traf...
So that's two different sources of clickstream data that mostly agree, 33% is too high but 20% is plausible. The numbers are not really going to get more accurate than that unless you can hack into Google.
But "a third" seems a bit misleading as the big pie chart in the second only shows 26% (closer to a quarter). From the bars in the middle of https://sparktoro.com/blog/2018-search-market-share-myths-vs... (also Jumpshot data) we can see that Google Images has been steadily decreasing in share, it might indeed have been a third in 2010-2014 but today is probably below 20%.
Then there's this Quora answer from 2010, it has a 1:5.5 ratio of images to search from Alexa, i.e 15%: https://www.quora.com/What-is-the-ratio-of-Google-Image-traf...
So that's two different sources of clickstream data that mostly agree, 33% is too high but 20% is plausible. The numbers are not really going to get more accurate than that unless you can hack into Google.
I wonder if these numbers are for traffic as in bandwidth or for discrete requests. Counting by bandwidth would explain the surprising representation of image search.
And if most image searched are searches for porn, then the total number of searches is perhaps not relevant.
And when I am searching for an image (and I never Google for porn), I am very rarely interested in the landing pages or text that comes up.
And when I am searching for an image (and I never Google for porn), I am very rarely interested in the landing pages or text that comes up.
I find the reasoning here mostly flawed.
> 1. Bad for SEO
How many image searches result in a visit? If my image search habits are typical then I'd say, not many. In addition, not all visits are good visits. In (nearly) 2020, traffic for the sake of traffic is a fool's errand.
> 2. Bad for Accessibility
Yes and no, but mostly no. The #a11y standard is to make sure AT __ignores__ decorative images. I would imagine most background images are for show (i.e., aesthetic for the sighted) and not actually part of the content. AT needing to "see" background images is fringe at best.
> 3. Bad for Performance
"How could the background-image property possibly be bad for performance? Because typically just one image is used for the background-image property regardless of the device screen width or resolution."
Misusing a tool doesn't mean you blame the tool.
> Link 4. Bad for CMS’s & CDN’s
Perhaps. But how often is this an issue? File this under "good problem to have" and then sort it out for that. It's not a reason to lash out against background-image.
p.s. Yeah, object-fit it a great. But it's not a reason to slag (the misuse of) background-image.
> 1. Bad for SEO
How many image searches result in a visit? If my image search habits are typical then I'd say, not many. In addition, not all visits are good visits. In (nearly) 2020, traffic for the sake of traffic is a fool's errand.
> 2. Bad for Accessibility
Yes and no, but mostly no. The #a11y standard is to make sure AT __ignores__ decorative images. I would imagine most background images are for show (i.e., aesthetic for the sighted) and not actually part of the content. AT needing to "see" background images is fringe at best.
> 3. Bad for Performance
"How could the background-image property possibly be bad for performance? Because typically just one image is used for the background-image property regardless of the device screen width or resolution."
Misusing a tool doesn't mean you blame the tool.
> Link 4. Bad for CMS’s & CDN’s
Perhaps. But how often is this an issue? File this under "good problem to have" and then sort it out for that. It's not a reason to lash out against background-image.
p.s. Yeah, object-fit it a great. But it's not a reason to slag (the misuse of) background-image.
I agree. Google nowadays show real SEO results below a huge amount of links. My entire blog is listing on 2nd pages, having the 100/100 pagespeed, best practices and 20 year domain record. Still I see the threshold around the 2nd/3rd page. Who goes there?
There are great points on SEO and accessibility, the latter which is sadly often an afterthought. However, the author does shoot themselves in the foot a little when the first "typical" example they offer is a div tag with an inline style="background-image: ...". It negates the the preceding point made on how it is bad for CMSes and CDNs and shackles them. Finally, advocating a polyfill to support the small number of users that don't need object-fit could potentially add more render-blocking for everyone if not done carefully.
While I can agree with the accessibility stuff usually, depending on how the feature is abused ... some of these arguments are pretty weak.
For example, for a lot of people the CDN and WAF are now bundled together and completely transparent. I.e. Cloudflare and StackPath's implementation.
For example, for a lot of people the CDN and WAF are now bundled together and completely transparent. I.e. Cloudflare and StackPath's implementation.
Article makes good points and how the <picture> element should be used instead.
It's surprising to see how many sites use background images on everything when they can use CSS but I can see developers simply implementing what the designer provided them with.
I use the the Wizmage Image Hider browser extension which disables all images by default which makes websites load so much faster and you can whitelist domain or individual images to always show.
It's surprising to see how many sites use background images on everything when they can use CSS but I can see developers simply implementing what the designer provided them with.
I use the the Wizmage Image Hider browser extension which disables all images by default which makes websites load so much faster and you can whitelist domain or individual images to always show.
The only problem I've found most annoying on using background-image on the CSS files is that you're bloating the CSS for nothing. You can inline that background file and remove a lot of KBs (assuming you use lots of backgrounds). The SEO part to me became irrelevant long time ago since all the traffic is driven by ad campaigns.
these are super weak. I dont need a background image indexed. there are plenty of ways to bundle and optimize images using webpack and the like. It sounds like someone using the least amount of tools available to make a case for a better tool, which plenty of exist...
Author here. I'm familiar with optimizing images via webpack and the like; there's an article I wrote on the same site as this one detailing just that (amongst other things):
https://nystudio107.com/blog/an-annotated-webpack-4-config-f...
The issue is that for many larger sites that are content-managed, the images aren't known at build time. So you need some kind of mechanism in place to deal with optimizing user-uploaded images.
Obviously you don't want truly decorative images indexed; but that's not what the article is discussing (except in the "SO WHEN IS IT GOOD?" section). It's discussing the abuse of CSS background-image for content images, something I've seen as being quite prevalent.
As the article mentioned, this is bad for accessibility, SEO, performances, and other lesser issues.
https://nystudio107.com/blog/an-annotated-webpack-4-config-f...
The issue is that for many larger sites that are content-managed, the images aren't known at build time. So you need some kind of mechanism in place to deal with optimizing user-uploaded images.
Obviously you don't want truly decorative images indexed; but that's not what the article is discussing (except in the "SO WHEN IS IT GOOD?" section). It's discussing the abuse of CSS background-image for content images, something I've seen as being quite prevalent.
As the article mentioned, this is bad for accessibility, SEO, performances, and other lesser issues.
That is not what indexing is wrt Google. They mean it won't be searchable.
Anyone remember the era when genuine background images were popular? Such as paper texture, greenbar paper, sparkles, and so on? Extremely geocities.
HN uses CSS background images for the vote arrows, and I've never understood why. Could it be exactly the screenreader thing?
HN uses CSS background images for the vote arrows, and I've never understood why. Could it be exactly the screenreader thing?
CSS sprites most likely. You can combine related smaller images into one image and then position the background image to an element so that only one portion of it is shown. This increases load speed and caching abilities since only one http request is made for the single combined background image.
the hn vote arrow is not a sprite - it's a single image, displayed rotated 180 degrees for the downvote.
https://news.ycombinator.com/grayarrow.gif
https://news.ycombinator.com/grayarrow.gif
Is there a proper alternative to CSS for sprite sheets yet?
Using SVG fragment identifiers seems to be the "modern way" https://caniuse.com/#feat=svg-fragment
Ah, wonderful! I remember there was some proposal to let # specify a part of a bitmap some years ago but it didn't take off, but that SVG supports it (in a better way) is great!
Edit: The thing I was thinking of was Media Fragments, apparently that has some browser support at least, but not for images? Hrm. You could put a PNG inside an SVG but that seems silly.
Edit: The thing I was thinking of was Media Fragments, apparently that has some browser support at least, but not for images? Hrm. You could put a PNG inside an SVG but that seems silly.
Yeah, Media Fragments is basically only implemented for partitioning videos based on time, not slicing bitmaps.
Putting a PNG/JPEG inside a SVG can be a valid strategy at times, but if you are using primarily bitmap sprites then the traditional way of positioning/clipping backgrounds is probably best.
Putting a PNG/JPEG inside a SVG can be a valid strategy at times, but if you are using primarily bitmap sprites then the traditional way of positioning/clipping backgrounds is probably best.
Object fit polyfills were iffy at best last I checked, though that only matters for IE11 (and Edge if using a non img tag).
this is one reason i like console browsers; i have a custom default css for it as well though. a lot of sites like to have there own rules for css and that is when general user css have to get into per-site css configuration especially your graphical browsers.
...and there is like 5 people doing that in 7.7 billion population.
I'm always stunned by god-like developers/designers who want to convince others that their way is better, completely forgetting that truly normal users don't care about anything discussed here or done by any other company. :)
I'm always stunned by god-like developers/designers who want to convince others that their way is better, completely forgetting that truly normal users don't care about anything discussed here or done by any other company. :)
I think the article makes some great points regarding SEO and accessibility benefits that should be followed. My sole gripe is against the title’s use of “anti-pattern” which 1) they fail to define 2) I associate with dark patterns (this is not that) and 3) use of back-ground image is definitely a pattern, sometimes a very useful one. What does he mean by anti-pattern in relation to background image? New Title: Why <picture> is superior to background-image:
Ok, we've taken anti-pattern out of the title in the hope of this conversation getting on to something non-titley.
Anti-patterns have nothing to do with dark patterns. Anti-patterns harm the developer accidentally, dark patterns harm the user intentionally.
https://en.wikipedia.org/wiki/Anti-pattern
https://en.wikipedia.org/wiki/Anti-pattern
Which is more serious, "anti-pattern" or "code smell?"
To me code smell is a clue that some code might be badly written. But it's not proof - and there could be good justification for the smell. An example would be a 500 line method.
Antipattern is more serious IMO because of the work "pattern", i.e. "something repeated". It is a repeated occurrence of doing something badly (in someones opinion!) across the code base. An example that comes to mind is making references to packages that you don't want structurally in your dependency graph, just to use a utility function.
Antipattern is more serious IMO because of the work "pattern", i.e. "something repeated". It is a repeated occurrence of doing something badly (in someones opinion!) across the code base. An example that comes to mind is making references to packages that you don't want structurally in your dependency graph, just to use a utility function.
I love the code smell of spaghetti code in the morning...
I counter with the dark pattern Wikipedia page: https://en.wikipedia.org/wiki/Dark_pattern
It's more about deception and persuasion than harm, like the modals that say "Sign-up for our 20-part email series on gold investment... [X] No thanks, I want to stay poor and uninformed"
It's more about deception and persuasion than harm, like the modals that say "Sign-up for our 20-part email series on gold investment... [X] No thanks, I want to stay poor and uninformed"
Generally tricking the user into doing something would be considered harmful.
Although it is an interesting question whether it's still considered a dark pattern if you trick the user into doing something that helps the user. For example in some videogames if you play for hours they'll give a popup telling you to take a break. What if that popup had the options "Sure" and "No, I don't care about my health". Or if you design a UI so that it's really annoying to order unhealthy food, but easy to order healthy food.
Although it is an interesting question whether it's still considered a dark pattern if you trick the user into doing something that helps the user. For example in some videogames if you play for hours they'll give a popup telling you to take a break. What if that popup had the options "Sure" and "No, I don't care about my health". Or if you design a UI so that it's really annoying to order unhealthy food, but easy to order healthy food.
I’d still consider it a dark pattern, as you’re still operating hostile to the user; you’re trying to get done what the user explicitly does not wish.
And absent nanny-state reasoning (which is really hard to justify in the hands of a no-name dev..), you really are operating user-hostile, even if your intent was not; no better than microsoft forcefully updating your OS for your security, eventually regardless of what you were doing (see guy in middle of 8 hr render process)
And absent nanny-state reasoning (which is really hard to justify in the hands of a no-name dev..), you really are operating user-hostile, even if your intent was not; no better than microsoft forcefully updating your OS for your security, eventually regardless of what you were doing (see guy in middle of 8 hr render process)
If you're feeling clever, you might call that an anti-dark pattern, a la "anti-hero", or really, anti-villain.
TBH, I hate these kinds of articles. Instead of titling it something like "Things to be aware of with CSS background-image", or even the catchier "Don't use CSS background-image for a foreground image", it uses a much broader, click-baity unwarranted title about "anti-pattern".
I'm glad that background-images aren't indexed by search engines, or made available to screen readers, and I obviously know they aren't downloaded before the CSS that references them is. I think all of those as good things, because I use background-image just for that - things that not primary. When I print, if excluding background images makes the page unreadable, I think of it as using background images wrong.
Calling a widely used, useful feature an "anti-pattern" just because some people may use it wrong is ludicrous.
I'm glad that background-images aren't indexed by search engines, or made available to screen readers, and I obviously know they aren't downloaded before the CSS that references them is. I think all of those as good things, because I use background-image just for that - things that not primary. When I print, if excluding background images makes the page unreadable, I think of it as using background images wrong.
Calling a widely used, useful feature an "anti-pattern" just because some people may use it wrong is ludicrous.
Ok, but the title isn't the article, and there are other things to discuss here.
https://news.ycombinator.com/item?id=20545932
https://news.ycombinator.com/item?id=20545932
Well, it is a common anti pattern, in the way it’s usually used. A quick search on github for uses corroborates this.
It may be an anti-pattern, but is it considered harmful?
At the very least it's user-hostile, if I want to save the image I would have to inspect element and open the URL in a new tab, rather than just Right Click > Save Image as...
Is it possible to write a WebExtension that realtime modifies HTML requests from remote sites to replace inline-CSS background-image with a <picture><img>? Those would be the cases most likely to be "we're doing a background-image out of laziness and/or to spite people trying to save images with long-press on mobile".
> Bad for SEO
> Bad for Accessibility
Good. I don't want my background images/textures to be indexed by search engines or shown to people with visual impairment. It's purely for presentation, and should be ignored by applications that only care about the content.
In fact, 95% of images on a typical web page these days seem to be ads, logos, and cute little buttons that have nothing to do with the content. Which means CSS background-image is perfectly fine for most of these images.
> Bad for Accessibility
Good. I don't want my background images/textures to be indexed by search engines or shown to people with visual impairment. It's purely for presentation, and should be ignored by applications that only care about the content.
In fact, 95% of images on a typical web page these days seem to be ads, logos, and cute little buttons that have nothing to do with the content. Which means CSS background-image is perfectly fine for most of these images.
The problem lies in people using background-image as the background of fluid design elements where it acts as an illustration with semantic content. Otherwise, it's OK to use as a decorative background.
In the case of buttons, it might or might not make sense, depending on each use.
I think the problem is frameworks shoving it all in the same place because "an image is an image is an image", which they shouldn't be doing.
In the case of buttons, it might or might not make sense, depending on each use.
I think the problem is frameworks shoving it all in the same place because "an image is an image is an image", which they shouldn't be doing.
"...or shown to people with visual impairment"
It's not about being shown to people with visual impairment. It's so that images that you felt relevant to convey to your sighted audience can also be conveyed to your visually impaired audience.
Buttons and logo have text that need to be conveyed. Figures important to a text need description.
People who build software get a bad rap for building inaccessible apps, and this line of thinking is why.
It's not about being shown to people with visual impairment. It's so that images that you felt relevant to convey to your sighted audience can also be conveyed to your visually impaired audience.
Buttons and logo have text that need to be conveyed. Figures important to a text need description.
People who build software get a bad rap for building inaccessible apps, and this line of thinking is why.
> It's so that images that you felt relevant to convey to your sighted audience can also be conveyed to your visually impaired audience.
Completely disagree. When used correctly, while background-image is an enhancement for sighted viewers, it's actually a distraction for visually impaired viewers where a screen reader needs to read the information sequentially.
Again, printing (where CSS background-images aren't shown by default) is a good test. If the printed page is still understandable, and actually easier to read on paper, without the background-image, it's probably a good use of the feature. If critical info is missing (stuff that would also be left out by a screen reader), it's a bad use of background-image.
Completely disagree. When used correctly, while background-image is an enhancement for sighted viewers, it's actually a distraction for visually impaired viewers where a screen reader needs to read the information sequentially.
Again, printing (where CSS background-images aren't shown by default) is a good test. If the printed page is still understandable, and actually easier to read on paper, without the background-image, it's probably a good use of the feature. If critical info is missing (stuff that would also be left out by a screen reader), it's a bad use of background-image.
The point made earlier is that most images are "buttons and logos", and while not part of the main text, understanding what they say is important to e.g. the navigation or context of the site. For that reason, it's no more clutter for users of screen readers than it is visual users.
The "printing a page" example doesn't work, because we still need to navigate pages, see logos, etc.
The "printing a page" example doesn't work, because we still need to navigate pages, see logos, etc.
Just don't use javascript for images and static content. It's better for SEO, for accessibility, it respects people's privacy, it works much faster.