best practice for show News list in html5 - css

In my page i need to list last news with title only. I have two methods:
One:
<div>
<p>Title One</p>
<p>Title Two</p>
<p>Title Three</p>
<p>Title .....</p>
<p>Title .....</p>
<p>Title .....</p>
</div>
Two:
<div>
<ul>
<li>TTILE ONE </li>
<li>TTILE Two </li>
<li>TTILE THree</li>
<li>TTILE .....</li>
</ul>
</div>
In HTML5 which way is better and readable?! with <p></p> Or <ul><li>?!

Neither is better in terms of how html can be read. However it is considered a list, and so your question can be answered by means of using <li>

You have there a list of news, so the correct one is UL.
The first option, using paragraphs is bad, because... Do you thing titles are paragraphs? I think title != paragraph, so uou can't use <p> tag.

Using an unordered list, <ul>, would be more semantically correct than using a paragraph, <p>.
Obviously either one could be used, so semantics may feel like a 6 vs half dozen sort of thing, but in the long run using the correct tags will make your job easier.
The <p> will come with native styles, i.e. margins and so on, that will need to be removed in your css if you intend you use them this way. While <ul> and <li> will probably only need to have bullet points accounted for.
Also not everyone experiences the web in the same way, try to keep in mind that screen readers will take markup into account when reading pages to the visually impaired.
In more extreme cases semantics can even effect your search engine optimization (SEO). Google, for instance, may grab your first paragraph and use it as a part of your site description.

Related

Trying to understand aria and accessibility

I'm updating a website, doing an iterative improvement on the accessibility.
I'm using multiple tools to get the pages better: FireFox's accessibility tree viewer; Chrome's lighthouse checker; the "wave" accessibility tool, and I'm trying tenon.io
(sadly, I don't have access to a decent screen reader - nvda is too fast for me to hear, orca seems to read the current line, and I don't have access to JAWS)
So here's what I have:
I have a navigation structure like this:
<nav aria-label="Main navigation">
<section class="desktop-navigation" aria-label="Main Menu">
<ul aria-label="Menu items">
<li>About Example</li>
<li>Documentation</li>
<li>Pricing</li>
<li>Status</li>
<li>Contact us</li>
</ul>
</section>
<section class="main-nav-wrapper" aria-label="Header logos">
<a href="/"><img src="/images/logo_example.svg?v=488a8c6971df396baaa401bb073b4a6b"
class="header-logo" alt="The Example logo" aria-label="Example Logo"/></a>
<div class="site-logos-right" aria-label="Corporate Logos">
<a class="external-link" href="https://www.example.com/" rel="external"><img
src="/images/logo_company.svg?v=98693292e027eca1f27cfc89b68a77d2" class="company-logo"
aria-label="The Company logo" alt="Official logo for Company"/></a>
<a class="external-link" href="https://example.com/department"
rel="external"><img src="/images/logo_department.svg?v=ff0114bb2ebf7eff339341f9554220d0"
class="edina-logo" alt="Official Department logo" aria-label="department logo" /></a>
</div>
</section>
</nav>
..... and this is 100% according the lighthouse, but tenon.io is reporting an issue (multiple times) and I don't understand why:
This element uses multiple strategies to create labels
This element has more than one possible label. The manner in which the
accessible name is calculated for controls uses an algorithm in which
only one of these labelling approaches will win. This means one of
these labels will be ignored by assistive technologies. There should
be only one label provided and the others should be removed.
Examples of items identified:
<nav role="navigation" aria-label="Main navigation">
<section class="desktop-navigation" aria-label="Main Menu">
<ul aria-label="Menu items">
<li><a href="/" aria-label="Return to the home page to read about
(I notice that the W3C site does not label the uls - but then they show as un-named elements in firefox)
I definitely want to label landmarks & sections.... so what's it actually complaing about?
<li>Pricing</li>
.... this is an example of where I want to have a more descriptive label for the element - when scanning the accessibility tree, just having the bare link-text doesn't (to me) read as well as having some context: as a sighted user, I know my eyes have flicked over much of the page, and seen additional text, so subconsciously have some context for the menu items.
My question(s)
How is the accessibility label computed?
Why can't I have a more descriptive label on a link? (lighthouse complains if the alt text doesn't contain the link text... but is happy if it's more than the link text) - or is this tenon.io being over-picky?
The accessible name computation is how accessibility labels are computed.
You're using aria-label too much, and the result may be difficult to listen to or outright confusing for human visitors using assistive technologies.
The first rule of ARIA is don't use ARIA unless you really have to.
It is appropriate to use aria-label on the <nav> and <section> elements. Keep that.
I can't think of any good reason to use aria-label on a <ul> element. I'd recommend removing that.
Using aria-label on anchor elements is normally unnecessary and should be approached with caution. Unless you have a really good reason, you probably shouldn't be presenting different content to visitors using assistive technology.
I would also recommend removing aria-label from your images. This is exactly what alt text is for.
If you really want to use aria-label on anchor elements, WCAG has some guidance:
Per the Accessible Name and Description Computation and the HTML to Platform Accessibility APIs Implementation Guide, the aria-label text will override the text supplied within the link. As such the text supplied will be used instead of the link text by AT. Due to this it is recommended to start the text used in aria-label with the text used within the link. This will allow consistent communication between users.
https://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA8.html#description
Don't give up on NVDA just yet. I also found the default speech settings too fast and difficult to understand. You just need to adjust the settings. The voice can also be changed out for better ones. It takes a bit of work to configure, but in my opinion NVDA is the best free screen reader available today. VoiceOver is also very nice if you have access to Mac/iOS products.

Div in li is it wrong usage?

example;
<ul>
<li>
<div class="img1"><img src="img.jpg" /></div>
<div class="cs1">Text text</div>
<div class="cs2">text text</div>
<div class="button">Next</div>
</li>
</ul>
like above code block div in li. I heard it is wrong usage. Is it true?
Both elements are block elements so nesting them is fine. Checkout the permitted content allowed in <li> in the Mozilla Documentation.
According to the W3C validator it is perfectly fine to use divisions.
you can also check your html whether it is valid or not in w3cvalidator
Hope this validator helps.
The best place to check it if you are in doubt is HTML DTD. It's a bit cryptic if you look at it first time, but it's a good source.
Let's look at your example:
http://www.w3.org/TR/html4/struct/lists.html#edef-UL
DTD stands that in UL (or OL) you can have only LI's (one or more)
<!ELEMENT UL - - (LI)+ -- unordered list -->
Then if you take a look on LI element:
<!ELEMENT LI - O (%flow;)* -- list item -->
it can take any element from the 'flow' shortcut (zero or more as the '*' stands for). You can click on the %flow link to learn what are those elements.
There is many other things you could learn from it, i.e. what kind of attributes given element can have etc.
No, it is often used by developers as easier CSS friendly dropdowns among many other uses you can probably think of.
The HTML syntax (any version) allows a div element inside an li element, as one can easily check from the specifications, or using a validator.
In any other sense than purely syntactic, the “wrong usage” issue is here really with the use of a bulleted list (ul element) with a single item in it. There is nothing formally wrong with it; it just does not seem to make any sense.
No it's not wrong use but it depends on what you want.
If you want a drop down menu every div must be inside a <li>
like the example shown below.
Eg:
<ul>
<li><div class="img1"><img src="img.jpg" /></div>
<li><div class="cs1">Text text</div> </li>
<li><div class="cs2">text text</div> </li>
</ul>

Using br or div for section break

I've worked at few places and seen two different methods of doing a section or line break in HTML.
One way I've seen it done is like this:
<div class="placeholder-100pct"> </div>
And the other is just using plain old <br />.
Any benefit to one over the other or would it be just a matter of style?
Use <br/> when you want a new line in a paragraph, like so:
<p>Hi Josh, <br/> How are you?</p>
This might be useful when writing an address:
<p>John Dough<br/>
1155 Saint. St. #33<br/>
Orlando, FL 32765
</p>
Using a div will automatically give you a new line, but if you want a space between two elements, you can use a margin on the div.
Do not use <br/> to get some space between two divs:
<!-- This is not preferred -->
<div>Hello</div>
<br/>
<div>Something else here</div>
Hope this helps
A div is a generic container. A br is a line break. Neither is particularly well suited for expressing a section break.
HTML 5 introduces sections. You mark up each section, not the break between them.
<section>
<!-- This is a section -->
</section>
<section>
<!-- This is another section -->
</section>
Use a <br /> when it makes semantic sense to do so. If all you need is a line-break, that's what it's there for. If you're trying to split sections of different types of content, then each section should be in a container of its own. For example, if you have an address where each line of the address would show on a separate line, it would make sense to do:
<address>
123 Main Street<br />
Anywhere, USA 12345
</address>
One obvious difference is that <br> is inline element, while <div> is not.
So this:
<span>Some text broken into <br /> lines</span>
... is valid HTML code, while this:
<span>Some text broken into <div> </div> lines</span>
... is not, as you cannot place block elements inside inline elements.
<br> has the disadvantage of limiting the size of your gap between sections to the line-height applied to or inheritted by the <span> it sits within.
In other words, with <br>, the size of the break can only ever be exactly the height of one line of text.
Definitely wrap each your "sections" in their own tags, and use margins to control spacing, if you want to retain any control over the spacing. The difference is not just in the semantics of markup.
If you are looking to provide a break between two sections of content in the sense of a thematic break, then <hr> is the element you should use.
W3C specification
The hr element represents a paragraph-level thematic break, e.g., a scene change in a story, or a transition to another topic within a section of a reference book.
It's also relatively straightforward to style these as needed as they can take whatever size you require. Note however that it is a void element and cannot contain content (although you can of course add a background-image to it as needed).

What should be the following tag to a span nested within an anchor?

I am trying to learn fundamentals of html and markings.
I want to create an anchor which containes two lines of information.
first line: the name of the link
second line: short explanation
e.g.
<a href='#'>
<span>Studies</span>
<span class="alt">-Information about studies</span>
</a>
Is this correct?
How should the following (2nd span) be modified if necessary?
Thank you
PS. Both lines need to be surrounded with span for css-styling.
First off, don't rule out using a br tag. This is a semantically-appropriate place for a br tag (forcing a hard break inside a line or paragraph of text). Plus, if you use a br tag, it may no longer be necessary to put either of the two lines of text in separate tags, unless you want to style them differently.
<a href='#'>
Studies<br/>
-Information about studies
</a>
Second, try viewing the HTML with stylesheets disabled (I do this in Firefox by pressing ctrl-shift-S, with a little help from the Web Developer extension). Is the browser able to render the content in an easy-to-read way based solely on the HTML provided? To some extent, the more readable the "unstyled" content appears, the more semantically-correct the HTML is.
Given that the second line of text seems to be secondary to the first line (a subtitle, not as important, possibly redundant or not entirely essential), putting the first line in a strong tag or putting the second line in a small tag are a couple ways to establish the relative importance of the two lines, if you wish to do so.
<a href='#'>
<strong>Studies</strong><br/>
-Information about studies
</a>
<a href='#'>
Studies<br/>
<small>-Information about studies</small>
</a>
There's some room for personal preference here. These are just two approaches.
It may be a little bit of a stretch using a small tag in a case like this, but it's not entirely inappropriate. A small tag is typically used for "fine print", attribution, disclaimers, or side comments. It doesn't semantically mean the text is small, but it does tend to be used for content that's secondary to something else (that clarifies something else). It should though only be used for text that's short in length.
And a strong tag doesn't have to be styled bold. In fact, that's the whole point of semantic markup: It doesn't specify or imply how the content will be styled; all it does is offer a hint to the meaning or context of the content. A strong tag can reasonably be given a style of font-weight:normal.
In order to achieve that those are in separate lines, try using the <div> tag instead. You can still specify a class for styling, the only difference is that <div>s are block-elements; each of them is rendered on a separate line. Here's the modified version of your code:
<a href='#'>
Studies
<div class="alt">-Information about studies</div>
</a>
Another, slightly more preferable way of doing that is by styling the elements to be block-elements. That can be used by setting the CSS display property to block. Something like:
<a href='#'>
Studies
<span class = "alt block">-Information about studies</span>
</a>
(Note that class = "alt block" means the element has both classes alt and block, and note also that the first <span> is removed because there's no need to style that node with anything).
CSS:
.block {
display: block;
}
Hope that helped you!

Hierarchal comments system

I'm doing frontend design and working with a couple of backend programmers right now--a process that is new to me.
We are trying to set up a system for comments complete with a hierarchy for replies. I thought the easiest way to style the different levels would be using nth child and nested lists, but I can't quite wrap my head around how to do that. Ideas?
As Ian has said, nth-child only works at one level at a time. If you wish to understand nth-child better, here are a few resources:
http://reference.sitepoint.com/css/pseudoclass-nthchild
http://css-tricks.com/how-nth-child-works/
http://www.impressivewebs.com/css3-pseudo-class-expressions/
http://lea.verou.me/demos/nth.html - this one is great, because it's
interactive
In any case, here is something you might want to consider: one thing that can be annoying in the case of hierarchical comments is the fact that, from a certain level, they can get so narrow it looks bad and it even makes reading a bit more difficult. This is why I favour limiting the number of levels - disqus, which was mentioned above, offers the option of limiting the number of nesting levels.
If you have a limited number of levels, let's say three or five, you can add classes for each level (top-level, second-level, third-level) and style them differently. Another option that you have, and this one does not depend on limiting the number of levels is to style odd and even levels differently by adding some odd-level/ even-level classes when you generate the HTML.
Basically, you would have something like this:
<ul class="comments">
<li class="comment first-level">
<div class="comment-data">[date, time, comment author, link]</div>
<div class="comment-body">[whatever is said in the comment]</div>
<div class="comment-footer">[reply option, show/hide comment thread option]</div>
<ul class="comment-thread">
<li class="comment second-level">
<div class="comment-data">[date, time, comment author, link]</div>
<div class="comment-body">[whatever is said in the comment]</div>
<div class="comment-footer">[reply option, show/hide comment thread option]</div>
<ul class="comment-thread">
[... and so on...]
</ul>
</li>
</ul>
</li>
</ul>
If I think better, you can add classes like level-1, level-2,... no matter how many levels you have.

Resources