What do I do to take advantage of Reader Mode in browsers to present a simplified, cleaner version of a web page?
I've used Google looking for information on how a page is coded or otherwise set up for reader mode and I have not found anything. Is there a document or web page somewhere that explains reader mode and how to set up a page which can take advantage of it?
There are no standards for how reading mode works, and it works quite different from browser to browser. You can help ensure reading mode works well with your sites by sticking to conventions for your document title, and providing certain metadata elements. I’ve documented this in detail here.
In theory: Do nothing.
Site authors generally don't like Reader mode - it hides their adverts, and throws away the design. It is designed to work in spite of sites and not require specific effort on their parts.
That said, it is more likely to work well when given high quality, well-structured markup.
Write valid HTML. Make use of semantic elements such as <main>, <nav>, <header>, <footer>, <h1-6> and so on.
Have you read this? https://mathiasbynens.be/notes/safari-reader
Here are the conclusion notes taken straight from the website
Conclusion
This definitely needs more investigating, but so far, these appear to
be the most important factors for Safari’s Reader functionality to
kick in:
Use the right markup, i.e. make sure the most important content is wrapped inside a container element. Whether you use article, div or even span
doesn’t seem to matter — as long as it’s not p.
The content needs to be long enough. Use enough words, use enough paragraphs, use enough punctuation. Every paragraph should have at least 100 characters.
Reader doesn’t work for local documents.
I think the essential thing is not only to use valid HTML, but to use HTML5 with everything it provides to structure a text semantically: <section> to have clearly seperated parts, <article> if you have thematically independent parts (like different blog posts / articles), <header> to clearly mark the header section, <h1> to <h6> for hierarchically different headers (where you should always be careful to never omit a level, i.e. for example not have an h4 directly in an h2 section, always use nav for navigation menus etc., paragraphs, lists, footers and so on...
BTW: <div>s don't have any semantic meaning, so you can use these (together with class attributes) to do whatever to tweak the result visually for "not-read-mode".
Related
We have inherited a website which we are currently trying to make WCAG2.0 AA compliant
One of the pages is failing the heading-order rule as it has an <h3> and <h4> tags but no prior <h1> or <h2>
We are in the process of adding an <h1> tag (as all pages should have one) but there is no need for an <h2> tag and to amend the <h3> and <h4> would involve a large refactoring of various jQuery code and CSS
Are there any tricks to make the page accessible? I'm loathed to put a hidden <h2> tag in as the screen readers would presumably pick this up. Or do they ignore the hidden tags and the page then becomes compliant?
Are you trying to satisfy WCAG 2.0 AA or are you trying to make the page accessible?
These are usually the same, but sometimes not.
A hidden <h2> would pass WCAG depending on how you hide it. That, however, would not make the page more accessible.
While this may suck, the best, most correct approach is to fix the <h3>s and <h4>s to become correct levels (that is my answer, the rest of this is fluff). Your question might be more appropriate if you instead provide some code samples and ask for tips on how to write a regex or otherwise script these replacements throughout the inherited system.
If you are being told you have no time to do it right, then code examples (or a sample site) might still be helpful to get some guidance.
I really have seen this situation before, and actually have fallen into this trap myself. By applying styles to the h3 and h4, it is possible to make a page look, well, a certain way.
Looking at the point of the header tags however, it is their purpose to add semantics to the document, as we all well know. Is it, therefore, meaningful to have a document outline where there is an h3 but no h2? Screenreaders and other accessibility tools use this header information and some could get confused.
My most influential decision-making point is, "how will the user consume this information?" Will they be able to consume it? Is it meaningful to skip a header level? I initially think not, but please let me know of your differing opinion!
If you really do care about accessibility, giving an empty h2 (even implicitly which is the case when you omit it) might give no clue, in some screen readers, of the announced section to users when they will navigate the outline of the document (1).
That being said, I can't find anywhere (neither WCAG or HTML5 documentation) where it's said that you can't omit one level of headings.
The only official (for HTML5.1) requirement is to use "headings of lower rank" to start new subsections, which should mean that you could use a h3 directly below a h1 but can't use another h1
Even the WCAG is giving an example using omitted ranks saying this example does not intend to prescribe the level for a particular section.
(1) HTML5.1 provides an outline algorithm where we can read about "implied headings" or about the use of the rank when there is an heading content element
I would say the best way to ensure compliance is to refactor the code that is in the javascript/CSS. To hide elements you could use the hidden attribute or aria-hidden.
https://www.paciellogroup.com/blog/2012/05/html5-accessibility-chops-hidden-and-aria-hidden/
I'm following the CodeSchool foundation course now with HTML. Its saying its 'not OK' to not have a <h2> heading as the top one:
we removed the h1 tag and replaced it with an img tag. That's fine, but it also means that our highest level heading right now is an h2 tag, which isn't OK.
Is this going to affect the final product or is it just a design thing?
Nothing will break if there is a h2 and no h1. However, the way computers read websites, is by parsing the HTML. The only way the computer knows that something is a top-level header (h1) is by finding the h1 tag.
The most common reason I can think of at the moment, as to why you want h1 insted of h2, is how search engines index your website. Using a h1, means that the text within the tag is highly relevant to your website, while h2 is not as important (but still more important than h3 for example).
So it's not about what works and don't works, but it's about what things should be. Writing a website, following all the "rules" of HTML, will make it easily parsable by crawlers (programs that parse websites and gather information).
Another, important, reason why your html should be well-structured is for blind people. They use programs that read out text from websites to "read" the website. Having bad semantic/bad structured html might make these programs useless.
Edit:
Sorry, as mentioned, document outline would break, but the website would still be rendered, which is what I was referring to.
The heading elements are used to provide semantic meaning to your content (as most HTML elements do). In addition, people who use assistive technologies, such as screen readers, rely on certain HTML elements to provide information as to how to navigate a page. The heading elements (h1...h6) help to create the page's Document Outline, for which there is a defined specification.
If you were to start with an h2, the outline would be broken.
Just as it makes no sense to stat a report on section 2, you should not start a web page there for the same reason.
SEO
Search Engine Optimalization! If a person searches for, say, "Rubik's Cubes", a search engine will look through their data to see which sites have the string "Rubik's Cubes" (or some substring or related words) on their site.
Now, if your site has the string "Rubik's Cubes" in an <h1> tag, the search engine will understand that this is the entire point of your page, and rank it higher, because it's the title of the entire page!
Meanwhile, if you have it in an <h2> it's probably just some part of the page, and that's fine too, but not AS good.
So while structurally, it makes no difference, think of SEO when you choose which header you use. If you're picking them just based on size, that's a bad idea. Just style them bigger/smaller instead!
A website I am working on uses Adobe Search&Promote (SP) as it's internal website indexing and searching tool.
I need to exclude common parts of each web page from being indexed by SP (such as the header, nav, footer) because they are the same on every single page.
SP's documentation states the following:
"To prevent parts of individual web pages from being searched, you can exclude portions of a page from indexing. Surround the text with <noindex> and </noindex> tags. This method is useful if you want to exclude navigation text from searches."
Of course, <noindex>, is not a standard HTML tag/element.
Is there javascript or something I should be doing to register/create this fake tag in browsers so I don't have to worry about any strange behavior as a result of having a non-standard HTML tag just hanging out in my code? Or should I just not care because browsers will ignore this non-existent element?
Note: There is absolutely no styling that needs to be done on this <noindex> element. It simply needs to wrap around content in the HTML.
There is nothing you need to do. Browsers are expected to ignore unknown tags, and they do, so they see <noindex>foo</noindex> just as foo. Well, not quite. Technically, modern browsers construct an element node (of type HTMLUnknownElement) in the DOM. But the element has no associated default styling and no associated action, so it’s really a dummy element and represents its content only.
It would be possible to remove such elements nodes using client-side JavaScript, but that would be quite unnecessary.
The only real risk is that some day some specification or some browser or some web-wide indexing robot might start treating noindex as a real element with some defined meaning, possibly with default rendering and default functionality. Then you would be in trouble if these differ from what you expected. But it’s a rather small risk, and it seems that you don’t have a choice.
Although it's not in the documentation, our team consulted an Adobe consultant regarding this. He told us that we can use a 'noindex' class instead of the <noindex> element. He was even recommending us to use the class instead of the tag.
A warning though, the 'noindex' class is only working with <div> elements but not on other elements such as <ul>, <header>, or <footer>.
So a usage will be something like this:
<div class="noindex">
<p>This should not be indexed.</p>
</div>
I use <h1>, <h2>, <h3> tags for headers. But then I almost always "overwrite" pretty much all styles (font size/family/weight, margin and padding).
Given this, is there any real reason to use them, other than their somewhat informative nature (that something is meant as a heading)?
Is there any real reason to use them, other than their somewhat informative nature
That is the ONLY reason to use them, to describe your document. That's the whole point of HTML, CSS is meant purely for styling.
There are exceptions for the non-semantic tags like div and span, but generally what you plan to do with your CSS should never affect your decisions on which tag to use to mark up your content, always use the appropriate one.
Yes, it's a good to define heading tags in your document. There are some good reason like
It's good to describe your document
It's good for SEO also
It's good to use heading tag when a screen reader set to a scanning mode.
Read this for more http://webdesign.about.com/od/beginningtutorials/a/headings_struct.htm
Heading markup is known to be significant to search engines (they give greater relative weight to text in them than copy test), though the details (including the importance of this issue) are not public information. Some screen readers and assistive software make use of heading markup, e.g. allowing “heading reading mode” and by making noticeable pauses before and after a heading. When an HTML document is opened in Microsoft Word, heading elements are recognized as headings that are used e.g. in generating a table of content. Headings are a widely known concept, so user style sheets may conceivably have settings for them, suitable for an individual user.
This description is not exhaustive, but it illustrates that for heading elements, the idea of “semantic markup” has some practical relevance.
I noticed that if you remove the nav element in HTML5, the list of links remain the same with or with out nav.
So, what is the use of nav in this case? What is it adding to me.
Yes,W3Schools.com mentions the following about nav:
The tag defines a section of navigation links.
But, as I mentioned, what is the use of adding a section that even if removed the impact will be identical?
Thanks.
Remember that HTML was, originally, intended to be a markup language to make digital copies of documents more accessible. Trends moved it away from that to a creative tool, but HTML5 seems to be returning to that original concept.
<nav> adds a specific type of unordered list – a list that indicates it is specifically meant as navigation. What this is 'adding to you' is a more universally identifiable document markup – whether you speak the language of the document or not, you can identify the regions to help you navigate. Yes, the screen readers, search engines, etc. have all been mentioned, but this is a human-friendly component as well. Looking solely at the source, one can identify how the document should be understood or organized. The potential benefit of this in document processing of all sorts (including PDF layout for publishers) is incalculable.
Remember that semantics carry the meaning of the words. You're marking up a portion of text so that text makes sense in context. <div> has no meaning, but <article>, <section> and <nav> all tell you what the text contained within the tags means to the overall document.
While you usually would write a <div id="nav">, you can now use <nav> instead. It's just more semantic and little else.
This will be helpful for mobile browsers and for other challenged environments where the user might want to have an easy jump at the navigation. It'll be easy for the browser to find the navigation that way.
Continue to use W3Schools as a reference source and you will go far ;)
Your question, might be better answered with taking a few examples... and then explaining why it matters...
But the TL;DR version is to do with semantics.
If you have a block of text, why do you wrap it in a <p> tag, when you don't need to. You can just as happily use a <span>, then set display:inline, set the margin-top:10px that a <p> uses and continue.
Also why do you wrap your content blocks in a <div>, it's to demarcate your content into meaningful areas.
Well that is kind of what does. It signifies to screen readers, search engines, and even your CSS selectors if you choose, that everything into of this tag, should semantically be considered as a navigation block.
You don't need it, but it will certainly help assign relevance to your page content.
It adds semantics. A screen reader could be coded to skip over nav elements automatically, or a search engine bot could be coded not to include text in the nav element in the search result snippet.
Right now there aren't any implementations of these use cases that I am aware of, but as you can just use a nav instead of a div, there isn't really any reason not to.