Front-End Checklist(github.com)
github.com
Front-End Checklist
https://github.com/thedaviddias/Front-End-Checklist
81 comments
Typically you’d use background images for something like that. Regardless, if you do have an image that doesn’t add anything to the information on the page give it an empty alt attribute to indicate to the screen reader that it shouldn’t try to read out the file name or something.
<img src=".." alt="">
Exactly. Every img element should have an alt attribute; those with visual content should have explanatory text in it.
What is the value of having an alt attribute if its value is blank? Just to tell someone poking at the source code that, "yeah, I know I'm supposed to have this, and it's intentionally left blank"?
No, the reason given was
> give it an empty alt attribute to indicate to the screen reader that it shouldn’t try to read out the file name or something
> give it an empty alt attribute to indicate to the screen reader that it shouldn’t try to read out the file name or something
:D I knew that. I'm not that noobish.
Let's see. If we use an image that doesn't add anything to the content, one would normally use background-attachment to add an image to say, the hero section.
(It seems you edited your comment?)
Good to know that the screen reader would try to read the file name if there isn't any alt text in it, I didn't know that. So, in the cases we do need to place an img in the document, then we simple place an empty alt text as in my above comment to tell the screen reader not to read the file name since it is only used for decorative purposes...?
Edit: I confused your comment with another one.
Let's see. If we use an image that doesn't add anything to the content, one would normally use background-attachment to add an image to say, the hero section.
(It seems you edited your comment?)
Good to know that the screen reader would try to read the file name if there isn't any alt text in it, I didn't know that. So, in the cases we do need to place an img in the document, then we simple place an empty alt text as in my above comment to tell the screen reader not to read the file name since it is only used for decorative purposes...?
Edit: I confused your comment with another one.
FYI, in HTML5 <img src=".." alt=""> is equactly equivalent to <img src=".." alt>. Value-less attributes become attributes with empty string values at the tokenizer level.
Hmm. Why not aria-hidden=true?
Seconding this. It very much depends on the purpose of the image. If an image or any other tag is extraneous in a screen reader context use the `aria-hidden`[1] attribute to exclude it.
A good example is an image used as an icon next to a text label. Imagine a link/button that contains the words "Save" and a floppy disk icon. There's no need to have an alt of "Save" on the icon as the text "Save" is already present. So it would look something like this:
[1] https://stackoverflow.com/questions/31107040/whats-the-diffe...
A good example is an image used as an icon next to a text label. Imagine a link/button that contains the words "Save" and a floppy disk icon. There's no need to have an alt of "Save" on the icon as the text "Save" is already present. So it would look something like this:
<a href="#"><img src="save-icon.png" aria-hidden="true">Save</a>
[1] https://stackoverflow.com/questions/31107040/whats-the-diffe...
The first rule of ARIA is don't use it if you don't have to. An img element with an empty alt attribute will tell the screen reader not to read it and is more widely supported than the aria-hidden attribute.
'aria-hidden' is for HTML elements that don't have their own way of hiding themselves from assistive technologies and for cases where you'll use JavaScript to change the element's hidden state. I can't think of a situation where you'd want to conditionally show and hide only an image only from screen readers but if you had that situation, toggling aria-hidden would be better than adding and removing the alt attribute's value.
'aria-hidden' is for HTML elements that don't have their own way of hiding themselves from assistive technologies and for cases where you'll use JavaScript to change the element's hidden state. I can't think of a situation where you'd want to conditionally show and hide only an image only from screen readers but if you had that situation, toggling aria-hidden would be better than adding and removing the alt attribute's value.
> Nobody wants to hear "bottom left corner of logo" or "rounded corner".
I would assume front-end guys care more about passing a Web Accessibility[0] audit than inconveniencing some users, thus good taste and wise discretion is spared for avoidance of litigation.
[0] https://www.w3.org/TR/WCAG20-TECHS/H37.html
I would assume front-end guys care more about passing a Web Accessibility[0] audit than inconveniencing some users, thus good taste and wise discretion is spared for avoidance of litigation.
[0] https://www.w3.org/TR/WCAG20-TECHS/H37.html
While that link is part of WCAG 2.0, there are other items within the standard to follow such as: https://www.w3.org/TR/WCAG20-TECHS/H67.html. Decorative images are not supposed to be read by the screen reader.
https://www.w3.org/WAI/tutorials/images/decorative/
https://www.w3.org/WAI/tutorials/images/decorative/
This recommendation would be fine 20 years ago. You should not have any decorative images in your markup, they belong to CSS.
Agreed but it does happen. Sometimes, the line between content and decorative it pretty thin.
Should you add an alt to a stock photo?
Should you disturb a user with a reading of "stock photo of a business man smiling" next to a sales paragraph? What about "sunset over a mountain" on a page for a SaaS website?
Should you add an alt to a stock photo?
Should you disturb a user with a reading of "stock photo of a business man smiling" next to a sales paragraph? What about "sunset over a mountain" on a page for a SaaS website?
Some people disagree but I think most say the stock photos should have alternative text. The photo is there for a reason, to convey something, and the text should indicate that (though usually not explicitly). Usually you don't use "photo" in alt text, the assistive technology will announce "image" with the text, and usually you don't want to call attention to the fact that an image is a stock photo. "Businessman smiling" or "smiling man in suit" would probably be good. You might add some adjectives that help convey why the image was used, "peaceful sunset over mountain."
The goal is not so much to make the best experience for the assistive technology user but to provide as close to the same experience as possible, bullshit marketing crap and all.
The goal is not so much to make the best experience for the assistive technology user but to provide as close to the same experience as possible, bullshit marketing crap and all.
Why? It shouldn't make any difference if you add alt="" to the img tag.
Because you shouldn't be using <img> tags for layout. Nobody does.
What's the reasoning behind such a rule?
Style is separate from content. ie. Screen readers/robots don't care about gradients etc.
I'm not seeing any practical benefits mentioned so this sounds like dogmatism to me. Using an img tag can sometimes just be more practical (e.g. if you're using a CMS or for use with a JS plugin). Google Image search definitely cares about images as well. I agree separating style from content has benefits but doing this at all costs isn't worth the time in my opinion and a few img tags seem harmless to me. It reminds me of how people are against JSX on principle that code and HTML should never be mixed without attempting to consider any of the benefits.
Practical benefit: users and search engines parse the content of the page for information about the subject matter, including Google Images. I agree having an img with an empty alt tag is OK, but it's not helping search optimization and neither is alt=round corner gradient (unless of course that is your subject matter :-)
Imagine reading a printed text page about dogs and peppered throughout the text was mentions of 'bezel flare 2' or similar. If it doesn't make sense for that to be on the page as text alone then it shouldn't be on the page at all.
Imagine reading a printed text page about dogs and peppered throughout the text was mentions of 'bezel flare 2' or similar. If it doesn't make sense for that to be on the page as text alone then it shouldn't be on the page at all.
It just doesn't sound significant to me. Crawlers and screen readers happily ignore div and span tags that add nothing to the content, they ignore mobile scaling meta tags in the head etc.
> they ignore mobile scaling meta tags in the head
Actually the meta viewport "Helps Google’s algorithms accurately assign indexing properties to the page rather than needing to signal the existence of corresponding desktop/mobile pages." [1]
Every bit of code on a page is interpreted a certain way for a reason. HTML5 now has more semantic tags like header and nav that add an additional layer of certainty over context. I'll concede that most developers seem to not care about the reasons why so long as they can push code to production faster.
[1] https://developers.google.com/search/mobile-sites/mobile-seo...
Actually the meta viewport "Helps Google’s algorithms accurately assign indexing properties to the page rather than needing to signal the existence of corresponding desktop/mobile pages." [1]
Every bit of code on a page is interpreted a certain way for a reason. HTML5 now has more semantic tags like header and nav that add an additional layer of certainty over context. I'll concede that most developers seem to not care about the reasons why so long as they can push code to production faster.
[1] https://developers.google.com/search/mobile-sites/mobile-seo...
So sad http://www.csszengarden.com/ is already forgotten :(
It is not! :) That website change the vision of CSS for lot of people.
Some people like myself work in places where there are still some clients that ask for IE6 compatibility and have to comply with WCAG 2.0 accessibility standards.
What makes it worth it for you to keep working there?
Note that you don't actually need the head or body tags in your page. The browser already knows what is allowed in the head. It looks weird at first, but you can write your html like so:
<!doctype html>
<html lang="en">
<title>My Title</title>
<div id="main"></div>
Edit: my original comment (retained below) is wrong about this being malformed, and it's completely valid. Some more info here: https://html.spec.whatwg.org/multipage/syntax.html#optional-...
---
Original comment:
The fact that browsers are able to handle malformed HTML doesn't mean that you should do it that way. There's no meaningful benefit that I can think of, and the potential to break a ton of things that aren't as lenient.
---
Original comment:
The fact that browsers are able to handle malformed HTML doesn't mean that you should do it that way. There's no meaningful benefit that I can think of, and the potential to break a ton of things that aren't as lenient.
The new craziness is basically that HTML is no longer structured as a tree, no more closing tags that don't semantically hold data, etc.
My understanding is that it is not malformed, but actually a part of the spec. Maybe someone else has a link to the appropriate part of the spec, but following someone else's link to the spec and reading it for myself is how I learned that it is not malformed.
>Tag omission in text/html:
>An html element's start tag can be omitted if the first thing inside the html element is not a comment.
>An html element's end tag can be omitted if the html element is not immediately followed by a comment.
https://www.w3.org/TR/html5/semantics.html#the-html-element
>An html element's start tag can be omitted if the first thing inside the html element is not a comment.
>An html element's end tag can be omitted if the html element is not immediately followed by a comment.
https://www.w3.org/TR/html5/semantics.html#the-html-element
It's not malformed in the traditional meaning, the HTML5 spec actually says that HTML, HEAD, BODY, etc. unambiguous tags can be omitted.
This is not malformed HTML. In fact, optional tags were in older HTML specs and are perfectly legal. Even in HTML 4.01 Strict.
See: http://rimantas.com/bits/minimal_html.html
Removing optional tags is recommended here: https://google.github.io/styleguide/htmlcssguide.html
These are very subjective, I've never done half of the 'high' priority items, and I've never had any issues with my site having a 'disfunction'. Take this list with a gigantic grain of salt.
For example, your site certainly won't break from missing the 'lang' attribute.
For example, your site certainly won't break from missing the 'lang' attribute.
No. But e.g. automated translation now needs to guess your language, and that's... not always successful. Screenreaders will need to guess the language to pronounce properly. Search engines will have to infer the language. And so on.
Your site isn't "broken", per se, but it's not as high quality as it could be.
Your site isn't "broken", per se, but it's not as high quality as it could be.
I wonder how much lang=en can actually be trusted—enough things put it in by default that I can easily imagine its presence on non-English pages.
Update: from elsewhere on this thread, Google ignores <html lang>:
> But the language attribute within the HTML markup is something we don't use at all. We've found that this language markup is something that is almost always wrong. So we tend to ignore that.
https://www.seroundtable.com/google-ignores-the-html-lang-at...
Update: from elsewhere on this thread, Google ignores <html lang>:
> But the language attribute within the HTML markup is something we don't use at all. We've found that this language markup is something that is almost always wrong. So we tend to ignore that.
https://www.seroundtable.com/google-ignores-the-html-lang-at...
It tends to be more reliable if it's not lang=en. The cargo culting nature of web development makes some things a bit painful.
FWIW, Chrome's translate feature does care about lang=. Or at least it did last time I checked.
It's one of the things that has no downside, and a small upside. If you leave it out, your site isn't horribly broken. People will always get the content, but tools that process the content might be wrong.
FWIW, Chrome's translate feature does care about lang=. Or at least it did last time I checked.
It's one of the things that has no downside, and a small upside. If you leave it out, your site isn't horribly broken. People will always get the content, but tools that process the content might be wrong.
submit a pull request
Seems like this could be presented without as much clutter. Not really useful at a glance for a checklist. Also, some of the info isn't well researched and lacks citations for claims as others have mentioned.
One would be better off just using the Google Web Starter kit[1], other boilerplate options, or just chrome dev tools running Audits to get started with a solid front-end.
[1] https://developers.google.com/web/tools/starter-kit/
One would be better off just using the Google Web Starter kit[1], other boilerplate options, or just chrome dev tools running Audits to get started with a solid front-end.
[1] https://developers.google.com/web/tools/starter-kit/
Following this list is a great way to never launch something into production.
Just keep a boilerplate handy
I've helped a friend to publish a one-page website over the weekend, and I believe it follows most of this checklist
I've helped a friend to publish a one-page website over the weekend, and I believe it follows most of this checklist
Seriously... surprised there isn't a tabs or spaces diatribe in there.
This would be a good checklist for anyone considering building a UI framework. This kind of thing is the reason Bootstrap & friends are so large - they do a lot for you.
I can't help but notice there's no "Security" section. Perhaps by the time you've got the HTML rendering it's too late, but SRI tags, CSP headers and whatnot all deserve some mention.
https://github.com/thedaviddias/Front-End-Checklist/issues/2...
https://github.com/thedaviddias/Front-End-Checklist/issues/2...
> All <img> have height and width set (Don't specify px or %)
So what unit should be used?
So what unit should be used?
None, image height and width attributes don't have the unit included.
(They generally assume these values are in pixels by default[1])
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/im...
(They generally assume these values are in pixels by default[1])
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/im...
Awesome list, I always forget about several things on here it's going to be nice to have a reference to prevent that from happening.
Here's a better checklist: Run a W3 validator on your HTML, fix the red stuff that isn't too annoying to fix. Launch. Deal with all that other stuff later.
<body lang="en"> - High?
why?
why?
I also found that odd. I've always placed mine in the HTML tag.
<html lang="en">
Putting it on <html> is better as that defines the language for <title> as well. The lang attribute defines the language of the tree that the element is the root node of.
still, who uses it for what? browsers dont change behaviour because of it, search engines ignore it, users dont see it.
1. The main reason is screen readers. Imagine a screen reader trying to pronounce ‘Je ne regrette rien’ with an English voice, then imagine the same with a French voice.
2. I’d be surprised if search engines didn’t use it at least as a flag for content language (although I’m sure that it‘s only supplemental at best).
3. Styling based on language. CSS has a :lang() pseudoclass selector so you can do p:lang(en) { color: red; } p:lang(fr) { color: blue; } . Or tie quote styles to language based on generated content. Or most usefully adjust font metrics based on language for multilingual sites (typically you’d want to boost the font size a little for Chinese or Japanese as there are less characters for same information, but each character is a little more dense).
2. I’d be surprised if search engines didn’t use it at least as a flag for content language (although I’m sure that it‘s only supplemental at best).
3. Styling based on language. CSS has a :lang() pseudoclass selector so you can do p:lang(en) { color: red; } p:lang(fr) { color: blue; } . Or tie quote styles to language based on generated content. Or most usefully adjust font metrics based on language for multilingual sites (typically you’d want to boost the font size a little for Chinese or Japanese as there are less characters for same information, but each character is a little more dense).
Actually, browsers do change behavior because of it[1], and users do get affected by it[2]. Google have said last year they ignore the lang tag but they do use the hreflang attribute[3]
[1] https://www.w3.org/International/tests/repo/results/the-lang...
[2] http://accessibility.psu.edu/foreignlanguages/langtaghtml/#a...
[3] https://www.seroundtable.com/google-ignores-the-html-lang-at...
[1] https://www.w3.org/International/tests/repo/results/the-lang...
[2] http://accessibility.psu.edu/foreignlanguages/langtaghtml/#a...
[3] https://www.seroundtable.com/google-ignores-the-html-lang-at...
I'd have thought things like that were better handled as a response header (same for the charset).
No, because pages can be saved, and then the page loses the information. Or rather, by all means do it (it does get the information to the browser quicker) but make sure you also add the information to the page.
I use VoiceOver sometimes which will switch to an appropriate voice for the language.
>Pixel perfect: High Pages are close to pixel perfect. Depending on the quality of the creatives, you may not be 100% accurate, but your page needs to be close to your template.
What is this 2004?
What is this 2004?
An oft overstated thing -- but the organization of CSS is currently being massaged by the front end community, and in-line CSS is no longer considered an awful thing with Radium and others.
I love the http://webdevchecklist.com/ site.
Pixel perfection, are we still striving for that?
Are sitemaps still a thing that really matters?
If you're coding it from scratch, don't bother.
If you're using wordpress or another pre-baked system, then it's worth having a sitemap plugin (example: Yoast SEO) or the built-in sitemap (like for Shopify).
Submit it to Google Search Console, Bing, and you're done (essentially).
If you're using wordpress or another pre-baked system, then it's worth having a sitemap plugin (example: Yoast SEO) or the built-in sitemap (like for Shopify).
Submit it to Google Search Console, Bing, and you're done (essentially).
Don't you wanna get crawled?
Have not found the crawl rates changed for sites where everything is well linked together. Then again, these have been just small sites with a few million pages.
measurability
crawling != indexing
with a segmented sitemap (i.e.: one per pagetype, per namespace, ..) you get important communicated to indexed ratios you otherwise do not get.
if crawling and indexing works, it works but if it doesn't you should know it (see it in google search console) and debug it (narrow it down via segmented sitemaps).
crawling != indexing
with a segmented sitemap (i.e.: one per pagetype, per namespace, ..) you get important communicated to indexed ratios you otherwise do not get.
if crawling and indexing works, it works but if it doesn't you should know it (see it in google search console) and debug it (narrow it down via segmented sitemaps).
Curious if you have examples of the types of sitemaps you mentioned: segmentation, namespacing, one per pagetype etc. and the reasoning behind the variations.
i.e.: tourradar.com/robots.txt
Actually I do work on a website that we do not want crawled. It would be handy to know which things to leave out to make it less likely your site will be crawled or show up high in a google result.
Just define a robot.txt file instructing the crawler to not index your website.
See: http://www.robotstxt.org/
See: http://www.robotstxt.org/
This is a common misconception:
https://support.google.com/webmasters/answer/7424835?hl=en#h...
> robots.txt Disallow does not guarantee that a page will not appear in results: Google may still decide, based on external information such as incoming links, that it is relevant. If you wish to explicitly block a page from being indexed, you should instead use the noindex robots meta tag or X-Robots-Tag HTTP header.
If it's something like a staging site, you'd be better putting it behind a login screen to prevent mistakes anyway.
https://support.google.com/webmasters/answer/7424835?hl=en#h...
> robots.txt Disallow does not guarantee that a page will not appear in results: Google may still decide, based on external information such as incoming links, that it is relevant. If you wish to explicitly block a page from being indexed, you should instead use the noindex robots meta tag or X-Robots-Tag HTTP header.
If it's something like a staging site, you'd be better putting it behind a login screen to prevent mistakes anyway.
It's already missing iPhone X support.
It will be interesting to find what the visitor percentages are for iPhone x.
Even though its Apple, at some point its not worth spending the time and money.
Even though its Apple, at some point its not worth spending the time and money.
The iPhone X will be sold out everywhere until 2018.
What would be a great idea is an app that scans for the presence of these conditions.
If anyone wants to have a crack at it, you can use Page.REST to build it. If not I might be able to get to it towards next week :)
Please don't do that. Don't put an alt on ALL images. Screen readers will read all of them. Skin and flavour images don't deserve to be read outloud. Nobody wants to hear "bottom left corner of logo" or "rounded corner".