I'm implementing a star-rating system on a product page. The current one is bloated and couldn't be considered semantic.
Is there a better way to approach ratings in HTML5 now (with for e.g. the <range> input)? Or failing that, what is the appropriate way to write the markup for a star-rating system?
For voting it is semantically a form (not a set of links, because this action has side effects, so must it use POST method). Stars could be radio buttons (with <label>!) or submit buttons (unfortunately this will be tricky to style).
<input type=range> would be more appropriate if you had rating in % or some larger scale. For a typical 1-5 rating it might not be the best solution:
The input element represents a control for setting the element's value to a string representing a number, but with the caveat that the exact value is not important, letting UAs provide a simpler interface than they do for the Number state.
For presenting the ratings, HTML doesn't have any specific elements, but you could use hReview or hReview-aggregate microformats or equivalent microdata (Google likes them).
I think the range input looks ideal for this job. In HTML <5, I think the most semantic way to do this is via a series of radio buttons. These can be styled to look like stars and scripted to behave as one would expect rating-stars to behave.
Additionally, for a static representation of a star rating the <meter> element should be suitable.
The meter element represents a scalar measurement within a known
range, or a fractional value; for example disk usage, the relevance of
a query result, or the fraction of a voting population to have
selected a particular candidate.
Related
I am creating a search form that has two elements an input field and a button. The input field does not have an label associated with it.
To make the field more accessible I can add <label for="searchfield">Search</label> and visually hide it so it will e.g. be accessible for screenreaders.
I could also add aria-label="search" to the input field and leave the input field without an label.
I have tested with "Voice Over" on a Mac and I get the same result/output. My question is are these approaches equivalent? Or is one approach better than the other one?
Here is a pen.
In the absence of having any knowledge of the site (how are other form fields labeled?) or the audience (what is their skill level or tech profile?), I approach these questions with a couple parameters:
The rules of ARIA (the first rule may apply here)
Progressive enhancement
That being said, I often code a page without ARIA and without CSS (as that may get blocked, chunked, etc) and make sure it is accessible.
That means I code a <label>. Then I visually hide it. If the CSS breaks, all is still well. If the user's screen reader does not support ARIA, all is still well. As an aside, if you think all screen readers of your users support ARIA, I encourage you to do to a tech assessment of users (local blind associations are a good start in the absence of any real users). Many people still run older versions of browsers and SRs.
For sighted users, I make sure I lean on contextual clues, like a clear search icon (or the word) in the button (as Unor references). Or maybe a placeholder with appropriate contrast (though you could use the <label> as a visual placeholder with some CSS trickery to hide it on focus).
If your submit button uses SVG, then I would be folding ARIA into that given the inconsistent support around SVG alternative text methods.
FWIW, I am also not a fan of the title attribute, partly because of inconsistent accessible name calculation and partly because I think it looks meh.
So, to answer your questions:
My question is are these approaches equivalent?
No, but the distance between them is shrinking.
Or is one approach better than the other one?
That depends on context we do not have.
Using aria-label is preferable to relying on CSS to visually hide a label element.
(Related Technique: Using aria-label to provide an invisible label where a visible label cannot be used)
But note that you don’t have to provide a label for a search form that only consists of the search field and the submit button. Assuming that you use a button labeled with something like "Search", it already makes clear which purpose the text field has.
(Related Technique: Using an adjacent button to label the purpose of a field)
In that case, while it doesn’t need a label, it should still get a name. One way to provide a name is to use the title attribute on the input element. The Technique Using the title attribute to identify form controls when the label element cannot be used shows this (a search form without label, with title attribute on input) in example 3.
I believe that aria-label="search" is the correct approach, as it produces cleaner markup (i.e. no unnecessary label tag) and no need for CSS to set visibility of the label - like in this example.
I believe visually hiding a label using CSS is a somewhat 'hacky' way to approach the problem, whereas ARIA is the standard for accessible markup, so it should be the obvious choice for situations like this.
On the other hand, it would be worth ensuring all browsers you intend to support can use ARIA correctly, and if not, it may be worth using the label approach to ensure compatibility across all browsers. Although, I think the support these days is pretty good, so that should not be a common scenario.
Why is it bad practice to have more than one HTML element with the same id attribute on the same page? I am looking for a way to explain this to someone who is not very familiar with HTML.
I know that the HTML spec requires ids to be unique but that doesn't sound like a convincing reason. Why should I care what someone wrote in some document?
The main reason I can think of is that multiple elements with the same id can cause strange and undefined behavior with Javascript functions such as document.getElementById. I also know that it can cause unexpected behavior with fragment identifiers in URLs. Can anyone think of any other reasons that would make sense to HTML newbies?
Based on your question you already know what w3c has to say about this:
The id attribute specifies a unique id for an HTML element (the id
attribute value must be unique within the HTML document).
The id attribute can be used to point to a style in a style sheet.
The id attribute can also be used by a JavaScript (via the HTML DOM)
to make changes to the HTML element with the specific id.
The point with an id is that it must be unique. It is used to identify an element (or an anything: if two students had the same student id schools would come apart at the seems). It's not like a human name, which needn't be unique. If two elements in an array had the same index, or if two different real numbers were equal... the universe would just fall apart. It's part of the definition of identity.
You should probably use class for what you are trying to do, I think (ps: what are you trying to do?).
Hope this helps!
Why should I care what someone wrote in some document?
You should care because if you are writing HTML, it will be rendered in a browser which was written by someone who did care. W3C created the spec and Google, Mozilla, Microsoft etc... are following it so it is in your interest to follow it as well.
Besides the obvious reason (they are supposed to be unique), you should care because having multiple elements with the same id can break your application.
Let's say you have this markup:
<p id="my_id">One</p>
<p id="my_id">Two</p>
CSS is forgiving, this will color both elements red:
#my_id { color:red; }
..but with JavaScript, this will only style the first one:
document.getElementById('my_id').style.color = 'red';
This is just a simple example. When you're doing anything with JavaScript that relies on ids being unique, your whole application can fall apart. There are questions posted here every day where this is actually happening - something crucial is broken because the developer used duplicate id attributes.
Because if you have multiple HTML elements with the same ID, it is no longer an IDentifier, is it?
Why can't two people have the same social security number?
You basicaly responded to the question. I think that as long as an elemenet can no longer be uniquely identified by the id, than any function that resides on this functionality will break. You can still choose to search elements in an xpath style using the id like you would use a class, but it's cumbersome, error prone and will give you headaches later.
The main reason I can think of is that multiple elements with the same id can cause strange and undefined behavior with Javascript functions such as document.getElementById.
... and XPath expressions, crawlers, scrapers, etc. that rely on ids, but yes, that's exactly it. If they're not convinced, then too bad for them; it will bite them in the end, whether they know it or not (when their website gets visited poorly).
Why should a social security number be unique, or a license plate number? For the same reason any other identifier should be unique. So that it identifies exactly one thing, and you can find that one thing if you have the id.
The main reason I can think of is that multiple elements with the same
id can cause strange and undefined behavior with Javascript functions
such as document.getElementById.
This is exactly the problem. "Undefined behavior" means that one user's browser will behave one way (perhaps get only the first element), another will behave another way (perhaps get only the last element), and another will behave yet another way (perhaps get an array of all elements). The whole idea of programming is to give the computer (that is, the user's browser) exact instructions concerning what you want it to do. When you use ambiguous instructions like non-unique ID attributes, then you get unpredictable results, which is not what a programmer wants.
Why should I care what someone wrote in some document?
W3C specs are not merely "some document"; they are the rules that, if you follow in your coding, you can reasonably expect any browser to obey. Of course, W3C standards are rarely followed exactly by all browsers, but they are the best set of commonly accepted ground rules that exist.
The short answer is that in HTML/JavaScript DOM API you have the getElementById function which returns one element, not a collection. So if you have more than one element with the same id, it would not know which one to pick.
But the question isn't that dumb actually, because there are reasons to want one id that might refer to more than one element in the HTML. For example, a user might make a selection of text and wants to annotate it. You want to show this with a
<span class="Annotation" id="A01">Bla bla bla</span>
If the user selected text that spans multiple paragraphs, then the needs to be broken up into fragments, but all fragments of that selection should be addressable by the same "id".
Note that in the past you could put
<a name="..."/>
elements in your HTML and you could find them with getElementsByName. So this is similar. But unfortunately the HTML specifications have started to deprecate this, which is a bad idea because it leaves an important use case without a simple solution.
Of course with XPath you can do anything use any attribute or even text node as an id. Apparently the XPointer spec allows you to make reference to elements by any XPath expression and use that in URL fragment references as in
http://my.host.com/document.html#xpointer(id('A01'))
or its short version
http://my.host.com/document.html#A01
or, other equivalent XPath expressions:
http://my.host.com/document.html#xpointer(/*/descendant-or-self::*[#id = 'A01'])
and so, one could refer to name attributes
http://my.host.com/document.html#xpointer(/*/descendant-or-self::*[#name = 'A01'])
or whatever you name your attributes
http://my.host.com/document.html#xpointer(/*/descendant-or-self::*[#annotation-id = 'A01'])
Hope this helps.
I just wondered and wanted to gather together in one place all missing features of our beloved html form elements.
One example could be missing of horizontal scrollbar in a listbox. But I am sure there are a lot of features we would like to see in our form elements by default.
One missing feature per answer please.
Thank you.
Date/Time picker controls, rather than always trying to manipulate a textbox, selects, or some other controls to create them.
Hell, they miss so many features, I wouldn't know where to begin! But here goes:
(Missing in HTML 4, don't know about 5)
Full visual customizability (background colours, borders, and text colours) for all elements (including checkboxes, radio buttons, and select elements)
Native input validation (without needing JS) for text inputs: Numeric only, alphabetic characters only, regular expression
An open enumeration, a "SELECT you can type in" would be handy in some situations.
If pretty much everyone, but not quite, answers the question in one of ten or 15 different ways, you have to either force everyone to type in the answer or have an "other" option with a separate text field.
The lack of intrinsic support for multiple windows (or even just modal dialogs) is ridiculous.
Think of the tens of thousands of programmer-hours wasted on acrobatic manipulation of div elements just to implement a UI that would be trivially easy in a desktop app.
It's somewhat pointless to list what is missing in HTML 4 since so much has been fixed in HTML 5. And then, most of us can't list what is missing from HTML 5 because we are not familiar enough with it yet.
I know it's very basic question and hope not so important, but i want to know the answer, please don't suggest only refer links.
we all daily face <input> type tag and their attributes (type, class, id, value, name, size, maxlength, tabindex etc..), I just want to know
is there any specific order required for attributes in <input> tag or can we use any order?
if there an order then what is it?
Already been answered, but my full and expanded answer is:
There is no predefined order for the attributes in terms of passing w3c validation... it's completely up to you.
However, you should introduce your own standard and stick to it.
If there are multiple coders working on the application they should all stick to the same standard.
If you are a team leader, web-dev business owner, manager, etc, it is your responsibility to encourage (and enforce) a culture that uses this standard.
When doing code reviews the attribute order should be checked, and anything that fails you should make the coder responsible fix it up... they'll only muck it up once or twice if they know they'll have to rewrite their code!!!
And why all this fuss and bother over attribute order?
This will increase code development and debugging speed.
It makes code more readable
It encourages the coders (or you) to pay attention to the little details
It helps to fosters an environment of "accountability for your own code"
My personal preference is:
type (so you can instantly see what it is)
id
class (I like to keep 2 and 3 together as they are the most common js/jQuery selectors)
name
value (I like to keep 4 and 5 next to each other so you can quickly reference what input it is and it's value).
All others (like checked, max-size, etc)
style
tabindex (I like 7 and 8 to be at the end as it's "non-relevant", in terms of the actual functionality, they are more styling/usability stuff, keep 'em out of the way!
You can use any sequence
Here's code guide from Mark Otto
General attribute order guide
He gives a general guideline to HTML CSS and JS although nothing specific about input tags alone. I think it's a good read.
The order of attributes in HTML elements doesn't matter at all. You can write the attributes in any order you like.
my preference is: id, name, type, class, attributes (like selected, checked), value
I have seen it a lot in css talk. What does semantically correct mean?
Labeling correctly
It means that you're calling something what it actually is. The classic example is that if something is a table, it should contain rows and columns of data. To use that for layout is semantically incorrect - you're saying "this is a table" when it's not.
Another example: a list (<ul> or <ol>) should generally be used to group similar items (<li>). You could use a div for the group and a <span> for each item, and style each span to be on a separate line with a bullet point, and it might look the way you want. But "this is a list" conveys more information.
Fits the ideal behind HTML
HTML stands for "HyperText Markup Language"; its purpose is to mark up, or label, your content. The more accurately you mark it up, the better. New elements are being introduced in HTML5 to more accurately label common web page parts, such as headers and footers.
Makes it more useful
All of this semantic labeling helps machines parse your content, which helps users. For instance:
Knowing what your elements are lets browsers use sensible defaults for how they should look and behave. This means you have less customization work to do and are more likely to get consistent results in different browsers.
Browsers can correctly apply your CSS (Cascading Style Sheets), describing how each type of content should look. You can offer alternative styles, or users can use their own; as long as you've labeled your elements semantically, rules like "I want headlines to be huge" will be usable.
Screen readers for the blind can help them fill out a form more easily if the logical sections are broken into fieldsets with one legend for each one. A blind user can hear the legend text and decide, "oh, I can skip this section," just as a sighted user might do by reading it.
Mobile phones can switch to a numeric keyboard when they see a form input of type="tel" (for telephone numbers).
Semantics basically means "The study of meaning".
Usually when people are talking about code being semantically correct, they're referring to the code that accurately describes something.
In (x)HTML, there are certain tags that give meaning to the content they contain. For example:
An H1 tag describes the data it contains as a level-1 heading. An H2 tag describes the data it contains as a level-2 heading. The implied meaning behind this is that each H2 under an H1 is in some way related (i.e. heading and subheading).
When you code in a semantic way, you basically give meaning to the data you're describing.
Consider the following 2 samples of semantic VS non-semantic:
<h1>Heading</h1>
<h2>Subheading</h2>
VS a non-semantic equivalent:
<p><strong>Heading</strong></p>
<p><em>Subheading</em></p>
Sometimes you might hear people in a debate saying "You're just talking semantics now" and this usually refers to the act of saying the same meaning as the other person but using different words.
"Semantically correct usage of elements means that you use them for what they are meant to be used for. It means that you use tables for tabular data but not for layout, it means that you use lists for listing things, strong and em for giving text an emphasis, and the like."
From: http://www.codingforums.com/archive/index.php/t-53165.html
HTML elements have meaning. "Semantically correct" means that your elements mean what they are supposed to.
For instance, you definition lists are represented by <dl> lists in code, your abbreviations are <abbr>s etc.
It means that HTML elements are used in the right context (not like tables are used for design purposes), CSS classes are named in a human-understandable way and the document itself has a structure that can be processed by non-browser clients like screen-readers, automatic parsers trying to extract the information and its structure from the document etc.
For example, you use lists to build up menus. This way a screen reader for disabled people will know these list items are parts of the same menu level, so it will read them in sequence for a person to make choice.
I've never heard it in a purely CSS context, but when talking about CSS and HTML, it means using the proper tags (for example, avoiding the use of the table tag for non-tabular data), providing proper values for the class and id that identify what the contained data is (and using microformats as appropriate), and so on.
It's all about making sure that your data can be understood by humans (everything is displayed properly) and computers (everything is properly identified and marked up).