What's the best practice regarding aria attribute translations? If a page is available in several languages, should aria attributes be too?
I am using react-i18next useTranslation hook to translate a site to a couple different languages, and I was wondering if I should also use the hook to translate my aria attributes.
I would limit the question a bit because not all ARIA attributes should be translated. In fact, most of them should not. For example, you don't want "true"/"false" (aria-hidden) translated to another language. You don't want "polite"/"assertive" (aria-live) translated to another language.
So you're really only talking about aria-label and aria-roledescription (the latter is not used very much). In ARIA 1.3, there will also be aria-description so it would be translated too.
But yes, if you translate the whole page (and set the lang attribute appropriately), you should also translate the aria attributes associated with string labels.
That's why I like using aria-labelledby instead of aria-label because the ID associated with the label will be translated (assuming it's a regular text HTML element) so your label gets translated for free.
As all text potentially presented by the user, of course they have to be translated.
All ARIA attributes containing plain text, such as aria-label, have to be translated, with the same care as if they were normally displayed on screen.
This is also true for alt attribute of images, sr_only text, etc.
As a screen reader user speaking several languages living in a country with several official languages and so very often face multilingual websites, I can confirm that it's a common annoying oversight.
Of course, all what is purely technical, such as IDs, true/false values, etc. don't need to be translated, as no user will ever see them.
It’s a common misconception that all UI text was visible or in text nodes. Often there are plenty of texts that will only be seen under certain conditions (states), or that will be read by machines, including search engines and assistive technology, before being presented to the user.
ARIA attributes that include human readable text are part of it and need to be translated.
I read articles about always trying to put text in a text node, for example by preferring aria-labelledby over aria-label. In my personal opinion, there are too many use cases where this is simply not possible. So we need a better approach anyway.
In HTML, examples for attributes that need localization, are:
Head Metadata including OpenGraph for sharing like <meta property="og:description">
alt attributes and title, also for <iframes> or <style> elements
label for video tracks
placeholder and pattern attributes if the format needs localization
value of inputs if not user-defined
Human-readable ARIA attributes aria-description, aria-label, aria-placeholder, aria-roledescription, aria-valuetext, aria-braillelabel
And also text
visually hidden by CSS, often via .sr-only or .visually-hidden classes
added by CSS’s pseudo-elements like ::before
Text parts with the lang attribute should not get translated and keep that attribute.
Relatedly, there is the translate attribute …
[…] that is used to specify whether an element's translatable attribute values and its Text node children should be translated when the page is localized, or whether to leave them unchanged.
Related
I've been seeing these attributes around on more modern websites like GitHub and such, and they always seemed to coincide with a customized popover like the title attribute.
Option 1
Option 2
Option 3
Option 4
I read some documents about data- attributes on HTML5 Doctor, and I'm not quite sure of the point.
Is there some SEO or accessibility benefit to using them? And what is the plugin(hopefully jQuery) commonly being used to create the popovers in this specific case?
Simply, the specification for custom data attributes states that any attribute that starts with “data-” will be treated as a storage area for private data (private in the sense that the end user can’t see it – it doesn’t affect layout or presentation).
This allows you to write valid HTML markup (passing an HTML 5 validator) while, simultaneously, embedding data within your page. A quick example:
<li class="user" data-name="John Resig" data-city="Boston"
data-lang="js" data-food="Bacon">
<b>John says:</b> <span>Hello, how are you?</span>
</li>
From : Ejohn.org 'Not sure about the external link policy, just putting it in here in case someone wants to know'
HTML5 data-* attribute is used for storing data in element
For manipulating with this attribute you can use jQuery.data() or .data() methods.
The main point is that data- attributes will not clash with attributes that may added to HTML later or with browser-specific attributes. The idea is to give an author a playground, a name space where he can use attributes for private purposes without fear of having them ever interpreted as standard or vendor-defined attributes in some different meaning.
According to this idea, search engines and assistive software ignore such attributes, as they have no interoperable meaning.
I have read on Mozilla website regarding the title attribute : "contains a text representing advisory information related to the element it belongs to".
But also, in the first paragraph of the page regarding all global attributes (title included): "HTML defines a few attributes that are common to all HTML elements. These attributes can be used on all elements, though the attributes may have no effect on some elements"
Is it anywhere specified (source please) on which element the title attribute has "no effect"?
I curious why this seems so vague, maybe I simply missed something.
I created a jsfiddle where title attribute seems to "have an effect" (on Chrome, FF29, IE11) on tags: <a>, <img>, <p>, <div>
It depends on HTML version where the title attribute is valid. Originally, it was allowed for links (a elements) only and was meant to help the user see, on mouseover, some information about the linked resource, useful for deciding whether to follow the link or not. This might still be regarded as the most useful way of using title.
Later, the attribute was allowed for most elements, and HTML5 proposes to remove all restrictions, mainly just for simplicity. The formulation about the effects is intentionally vague, since the effects are expected to be browser-dependent, and they often are. For example, speech-based browsers may optionally speak the title attribute value when encountering an element that has it; but this can usually be switched off.
For example, in HTML5, the title attribute is also allowed for a head element, but it normally has no effect there, since that has no content to be rendered (as part of the document).
The title attribute is mostly used to show users information (“tooltip”) on mouseover. This is in many ways problematic, due to the primitive and uncontrollable user interface and other problems. Therefore, people often use other techniques, such as “CSS tooltips”, instead. But for compatibility with past specifications and practices, title attributes are kept as part of the language. It is unlikely that its meaning will be specified more exactly.
I've been seeing these attributes around on more modern websites like GitHub and such, and they always seemed to coincide with a customized popover like the title attribute.
Option 1
Option 2
Option 3
Option 4
I read some documents about data- attributes on HTML5 Doctor, and I'm not quite sure of the point.
Is there some SEO or accessibility benefit to using them? And what is the plugin(hopefully jQuery) commonly being used to create the popovers in this specific case?
Simply, the specification for custom data attributes states that any attribute that starts with “data-” will be treated as a storage area for private data (private in the sense that the end user can’t see it – it doesn’t affect layout or presentation).
This allows you to write valid HTML markup (passing an HTML 5 validator) while, simultaneously, embedding data within your page. A quick example:
<li class="user" data-name="John Resig" data-city="Boston"
data-lang="js" data-food="Bacon">
<b>John says:</b> <span>Hello, how are you?</span>
</li>
From : Ejohn.org 'Not sure about the external link policy, just putting it in here in case someone wants to know'
HTML5 data-* attribute is used for storing data in element
For manipulating with this attribute you can use jQuery.data() or .data() methods.
The main point is that data- attributes will not clash with attributes that may added to HTML later or with browser-specific attributes. The idea is to give an author a playground, a name space where he can use attributes for private purposes without fear of having them ever interpreted as standard or vendor-defined attributes in some different meaning.
According to this idea, search engines and assistive software ignore such attributes, as they have no interoperable meaning.
<p>...the favourite color of Purple is purple...</p>
the first "Purple" is a name of a company, the second one is a color name,
how should I markup this according to html5 spec?
thank you in advance
You have a number of options:
Leave it as is, HTML isn't really concerned with semantics which aren't about describing document structure (paragraphs, headings, lists etc.). If you do want to express more detailed document or application semantics look at WAI-ARIA.
If it's important for you to distinguish between the two uses of the word purple as part of your website or app then use the class attribute or data-* attributes
If the words have canonical machine readable forms and you want the values to be parsed by a computer somehow, use the data element.
If distinguishing between the two uses is important to users or systems consuming your site content, use the semantic extensibility feature of HTML5: Microdata. (If you're using the XML dialect of HTML, see also: RDFa)
Combine any of the above approaches according to your immediate needs.
To decide between the approaches you should ask yourself:
For what purpose do I need to extend the semantic vocabulary of HTML?
Is it for my own uses, or am I trying to publish information to be used by others?
If I'm publishing for others, what shared vocabulary am I going to use?
Code examples:
Class attributes
What they're for is adding additional information to your markup, remember the class attribute is in the HTML spec, not the CSS spec:
<p>...the favourite color of <span class="company">Purple</span>
is <span class="color">purple</span>...</p>
Having said that, of course, the obvious thing to do once you have things marked up in this way is provide in page tools to do things like 'highlight all companies'. People have used the class attribute as the basis for a general purpose semantic extension mechanism however, for this approach taken to the extreme see microformats.
Data attributes
The data-* attributes are to allow you to add custom attributes to your markup for processing with scripts in a way which guarantees you won't accidentally use a custom attribute which then gets used in a future version of HTML:
<p>...the favourite color of <span data-typeofthing="company">Purple</span>
is <span data-typeofthing="color">purple</span>...</p>
It's up to scripts on your page to do something useful with the data-* attributes, browsers and other web clients will ignore them.
Custom data elements
Data elements are for things that have an imprecise natural language expression but also a precise machine readable expression. Assuming that the company can be uniquely identified by a ticker symbol and RGB will do for the colour:
<p>...the favourite color of <data value="purp">Purple</data>
is <data value="rgb(128,0,128)">purple</data>...</p>
Browsers probably won't do anything special with the data element. It's most likely you'll use data elements in concert with microformats, RDFa or Microdata.
Microdata
Using the Organization schema:
<p>...the favourite color of
<span itemscope itemtype="http://schema.org/Organization">
<span itemprop="name">Purple</span>
</span>
is purple...</p>
There isn't anything for colours that I'm aware of, but you could always publish your own schema for that if it's important to you. This approach only really benefits anyone if there is a shared vocabulary of some kind.
Which element?
The first task would be to decide which element should be used to enclose the "entities" (company name and color name). Most probably you want to use span here. If in doubt, use span. There are some cases (depends on content) where other elements could be used:
the b element might be used if the entity is some kind of keyword ("a span of text to which attention is being drawn for utilitarian purposes without conveying any extra importance and with no implication of an alternate voice or mood")
if the entity is the title of a work (book, film, song etc.), the cite element should be used.
the dfn element might be used if the entities are defined in the same paragraph or in the nearest ancestor sectioning element
in some cases the i element could be appropriate
If the term is an abbreviation/acronym, use the abbr element (instead of span resp. in addition to b/dfn/i).
A good idea might be to use the a element to link the entity name to a relevant webpage. The rel attribute might give additional metadata (you can use the rel values listed in the HTML5 spec, or the registered rel values in the microformats wiki), depending on the content/context.
Which attributes?
Have a look at the global attributes.
The class attribute would be used if you'd like to use microformats. You could of course use other class names, but they would only be useful for yourself (documentation, CSS, JS) or other people that read your markup (documentation, scraping).
For entity names like person/company names you probably want to use the translate attribute with the no keyword, because such names should not be translated.
The title might give additional information (note that it has special semantics for dfn/abbr), but don't rely on it for important information.
Use lang if the entity names are in a foreign language.
How to annotate the content with meaning?
There are three popular choices, which can also be used together (see this answer (the "third step") for a short summary of the differences):
microformats
RDFa
microdata
You may need additional elements; if so, use span.
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).