url: http://translate.google.com/
eg. source lang is english, translate lang is other. and enter the text 'i' in the above page's textarea. hover the translate word, and the word background will highlight, and the 'i' will highlight.
I want to know that blew the code how does the '.gt-hl-layer' cooperate with the '#source' work?
<div style="width: 100%;"><!--from google translator-->
<div class="gt-hl-layer" style="box-sizing: content-box; width: 641px; height: 65px; left: 0px; top: 0px; " dir="ltr"></div>
<textarea id="source" name="text" wrap="SOFT" tabindex="0" dir="ltr" spellcheck="false" autocapitalize="off" autocomplete="off" autocorrect="off" style="overflow-y: hidden; overflow-x: auto; box-sizing: border-box; " class="goog-textarea"></textarea>
</div>
It's better to give some simple demo or code.
thanks very much!
I imagine it could work like this:
Run source through the "translation machine", it produces the translated text, and in the process does a lot of tagging (annotations) on the source -- the translation also comes with annotations.
The translation process determines which tokens in the source are linked to each other (e.g. phrasal verbs) and how the tokens are linked to the corresponding elements in the translation.
The translation text is an end product, it's generated from a dataset which had much richer annotations and tags -- using this richer set, you can have this annotated structure compiled into any other format (say, XML), or in the case of HTML, it probably takes the form of lots of spans, each with an ID.
On the surface, the HTML is re-fabricated for the source text too (now with the structure from the underlying annotations). It's like a tokenized text with lots of spans, each with an generated ID. Usually there's another layer that matches the text areas and carries the highlighting.
Then probably there's a middle part that map out which mouseover in the translation should light up which span(s) in the source.
Related
<span tabIndex='0' aria-label={ariaLabelText} className={classesContainer}>
<span className={classesItem}>{cartItemCount}</span>
</span>
I am trying to read the cart item count
As you will discover from this excellent resource aria-label is not supported on <span> because WAI-ARIA specifies <span> as a 'generic' role, which in turn means that it cannot be named.
You can (of course) override the default role by adding a role attribute which supports naming. Choose wisely. If this is going to be keyboard focusable (which your tabindex value suggests) then you should choose an operable role, such as button or link. Better still, use the HTML5 equivalent : <button> or <a> respectively.
In this particular case, where you simply want to announce the number of items in a cart, I would assume that the 'cart' itself is some kind of button, or perhaps a hyperlink, and the number of items in the cart is a kind of description or annotation for that element.
Your 'cartItemCount' can be included as part of the name, or not as you prefer. In the example below, it is excluded from the name by aria-hidden.
Alternatively, an annotation such as this might call for aria-describedby, so you might do something like this:
<button class="cart" aria-describedby="cartItemCount">
<span class="visibleLabel">{ShoppingCartText}</span>
<span aria-hidden="true" id="cartItemCount" class="items">{cartItemCount}</span>
</button>
In this example, 'cartItemCount' span is excluded from the button's accessible name (using aria-hidden) yet still exposed to assistive technology via aria-describedby.
As a design consideration, the 'description' of aria-describedby is something which assistive tech users might prefer to disable, relying wholly on naming (at least sometimes), so your annotation might not be 'announced' if it is not part of the name.
Screen readers and other ATs will offer different ways of accessing or muting this 'description' value when an element is in focus.
Note: The ARIA annotations spec, not quite final at time of writing is slated for inclusion in WAI-ARIA 1.3. It offers the aria-description attribute (already supported on some browsers) which will allow such state annotations to be added without creating additional elements.
The VoiceOver screen reader on Mac is able to read each element in the page by using Control-Option + left/right/up/down.
Since you are using aria-label then you are simply overwriting any text which would be presented inside the span. So, your span would need to use `aria-label="{ariaLabelText} {cartItemCount}"
However, why not simply add everything as a bit of text inside the span and be done with it?
I suspect you want to display a number, be able to tab to that cart number and when you reach there via VoiceOver you want to be able to reflect some extra bit of text to the screen reader users.
For that you need to do something different:
<button>
<span class="visually-hidden">{cartItemText}</span>
<span class="items">{cartItemCount}</span>
</button>
And below is the CSS for the visually-hidden class:
.visually-hidden {
clip: rect(0 0 0 0);
clip-path: inset(50%);
height: 1px;
overflow: hidden;
position: absolute;
white-space: nowrap;
width: 1px;
}
This way you have interactivity, text displayed in numbers for visual users and also text read out aloud for screen reader users.
Let's take an Open Library list page for example. When you visit the page, one of the first things that a user with a screen reader would hear is "link, Mek". Mek is the username. However, in the case of social websites someone could pick any username like "borrow the book" or things that I imagine would be disorienting to people using screen readers.
So, my question is, would it be appropriate to use something like aria-label to say that it is a username since that is not otherwise written on the page? If not, is there another way that people using screen readers deal with this?
I'm new to A11Y and ARIA so maybe I'm looking in the wrong place for answers. I have tried searching this in may ways and read some documents like Using aria-label for link purpose and Using aria-label to provide an invisible label where a visible label cannot be used.
I also looked at the code on social sites such as Twitter, Reddit, and Facebook but as far as I can tell none of do anything special for usernames. Perhaps it is less important for sites that are primarily user generated content.
Linked Example
In the example page you linked those are actually breadcrumbs so technically make sense.
<div class="superNav">
Mek
/
Lists
</div>
With that being said they should be located within an unordered list (as an unordered list is useful for screen reader users to know how many links there are as it will read "1 of 2 option" or similar) and have some form of identification on the <nav> (so it is not considered main navigation):
<nav aria-label="breadcrumbs" class="superNav">
<ul>
<li>
Mek
</li>
<li>
Lists
</li>
<ul>
</nav>
Finally if you have a sophisticated back-end or the first link will always be a link to a user profile then you could add some visually hidden text to the link just for clarity.
HTML
[...]
<ul>
<li>
<span class="visually-hidden">User Profile for </span>Mek
</li>
[...]
CSS
.visually-hidden {
border: 0;
padding: 0;
margin: 0;
position: absolute !important;
height: 1px;
width: 1px;
overflow: hidden;
clip: rect(1px 1px 1px 1px); /* IE6, IE7 - a 0 height clip, off to the bottom right of the visible 1px box */
clip: rect(1px, 1px, 1px, 1px); /*maybe deprecated but we need to support legacy browsers */
clip-path: inset(50%); /*modern browsers, clip-path works inwards from each corner*/
white-space: nowrap; /* added line to stop words getting smushed together (as they go onto seperate lines and some screen readers do not understand line feeds as a space */
}
Social sites
However for social sites there are loads of things you can do.
For example if the image is a link to their profile you can use the alt attribute to indicate the action of the link.
<a class="profile-container"
<img src="profile-image-user-rayb.jpg" alt="RayB profile page" />
</a>
If it is just a static image (and their username is not shown anywhere else) then the alt attribute would change with the context.
<img src="profile-image-user-rayb.jpg" alt="RayB profile picture / avatar" />
If it is a static image and the persons name is located somewhere else within that article / block then you would likely hide the image:
<article>
<h2>Some article Title</h2>
<img src="profile-image-user-rayb.jpg" alt="" role="presentation" aria-hidden="true"/>
<p class="written by">Author: RayB</p>
</article>
** please note:** in the last example an empty alt attribute is sufficient to hide an image from a screen reader. I add role="presentation" and aria-hidden="true" so that I can check for empty alt attributes that are mistakes (e.g. if they do not have aria-hidden="true" then I know they should have an alt attribute filled in).
Why so many variations?
This is where accessibility turns from a set of rules into an art form, you have to pick the best option depending on the circumstances.
A good place to start for alt attributes for example is the alt text decision tree from W3.
Other than that consider things like:
does this add additional information a screen reader user needs?
Is the information available elsewhere / nearby and does this then just duplicate it?
If this is an image in a link does the alt attribute reflect the action of the link in context. etc....
Above all, grab a screen reader and try it, that is without doubt the quickest way to learn (as you can identify an issue / something that confused you / repetition etc. and then it is easy to look for a fix/).
If you need more info just let me know!
I am using rich snippets on my site, I have all of the code for them in the footer so that they are centrally located and easy to access. I do not want the text around these snippets rendered on the page because that info is elsewhere on the site. Is it ok to hide this text by using style="display:none" or will Google ignore the rich snippet entirely because the fields are hidden?
<!-- start rich snippet code -->
<div itemscope itemtype="http://schema.org/LocalBusiness">
<span itemprop="name" style="display:none">My Business Name</span>
<div itemprop="address" itemscope itemtype="http://schema.org/PostalAddress">
<span itemprop="streetAddress" style="display:none">123 Example Street, Suite 456</span>
<span itemprop="addressLocality" style="display:none">Major City</span>
<span itemprop="addressRegion" style="display:none">NY</span>
<span itemprop="postalCode" style="display:none">12345</span>
<span itemprop="addressCountry" style="display:none">US</span>
</div>
<span itemprop="telephone" style="display:none">(123) 456-7890</span>
<a itemprop="URL" style="display:none">http://www.mycompanysite.com/</a>
</div>
<!-- end rich snippet code -->
Any info would be much appreciated! Thanks in advance!
As #Diodeus said, ideally you'd have these rich snippets on the actual info that is shown to the user elsewhere on the site. Duplicating it is usually unnecessary.
Yes, Google may well ignore this content based on the display:nones. Can I ask why you're setting it on each element rather than just once on the highest level div?
A way around the display:none potential SEO issue would be to hide it in a different way. For example give the parent div a class of .visuallyhidden and add this to your stylesheet:
.visuallyhidden {
border: 0;
clip: rect(0 0 0 0);
height: 1px;
margin: -1px;
overflow: hidden;
padding: 0;
position: absolute;
width: 1px;
}
I would like to mention that Google tries heavily (using combination of algorithmic and manual things) to find websites which illegitimately use hidden text.
The typical penalty for that would be a removal from index for 30 days. However, you should not be concerned if you use hidden fields legitimate ways.
There is a very nice article Eric Enge Interviews Google's Matt Cutts regarding Google attitude toward illegitimately use of hidden text.
Have a look at this: https://sites.google.com/site/webmasterhelpforum/en/faq-rich-snippets and search for the word 'tempting'.
' It can be tempting to add all the content relevant for a rich snippet
in one place on the page, mark it up, and then hide the entire block
of text using CSS or other techniques. Don't do this! Mark up the
content where it already exists. Except in special circumstances ... '
It might seem like a clever idea to hide elements in a more complex way than by just display:none but, and i guess the same can be applied for hidden honeypot form fields, you are not the only one who can think of that.
Note: It is as easy to determine if a field is hidden by display:none as it is by margin:0; padding:0; width:1px; height:1px; overflow:hidden or by position:absolute; top:-[a value bigger than the page height]px or by something similar.
People would rich-snippet everything as an Apple product page if it would be ok to hide the snippet and provide any other kind of information on the porn - i mean page.
You got all that information already hanging out on the site, so just add the correct microdata tags to the corresponding text passages and google (other search engines, too by the way) will be happy.
So, for example, if your main page title already exists, put the itemprop="description" tag in the <div> tag thats is wrapping the title and you should be fine.
:)
I've been working on a page where there are several entries contained in different <div>s. Each is only a title linked to a page, an image and a short description. However, the description may contain arbitrary tags, including <a> tags.
Since these are pretty straightforward and the actual link isn't that big, I've made it so a click on the <div> will call location.href = (link URL). However, that's a pretty sad thing, because it's browser-unfriendly: for instance, under Google Chrome, a middle-click on one of said <div>s won't open the link in a new tab.
Considering you shouldn't nest <a> tags, is it possible to make any element in XHTML behave like a link without resorting to Javascript?
I'm using XHTML 1.1, sent with the proper MIME type, and that's the only restriction I'm bound to.
Not really, no. Though it's worth reading Eric Meyer's thoughts on this. Also, it appears that HTML51 includes the capacity for any element to become a link, so it might be worth using that doctype instead of xhtml, if possible.
It's worth also adding that html 5 does allow for an <a> element to enclose block-level elements, see: http://www.brucelawson.co.uk/2008/any-element-linking-in-html-5/, example taken from the linked page:
Instead of:
<h3>Bruce Lawson as Obama's running mate!</h3>
<img src="bruce.jpg" alt="lovegod" />
<p>In answer to McCain's appointment of MILF, Sarah Palin, Obama hires DILF, Bruce Lawson, as his running mate. Read more!</p>
you can say:
<a href="story.htm">
<h3>Bruce Lawson as Obama's running mate!</h3>
<img src="bruce.jpg" alt="lovegod" />
<p>In answer to McCain's appointment of MILF, Sarah Palin, Obama hires DILF, Bruce Lawson, as his running mate. Read more!</p>
</a>
Updated to mention possible inaccuracy
1: I may have misinterpreted part of the document to which I linked, having tried to find support for my claim that '...appears that HTML5...any element to become a link' (in the W3C's html 5 overview) it doesn't seem to be there. I think I was over-encouraged when I saw Meyer's proposal to include that possibility.
I'm too gullible, and naive... =/
If you want a link to cover an entire div, an idea would be to create an empty <a> tag as the first child:
<div class="covered-div">
<a class="cover-link" href="/my-link"></a>
<!-- other content as usual -->
</div>
div.covered-div {
position: relative;
}
a.cover-link {
position: absolute;
top: 0;
bottom: 0;
left: 0;
right: 0;
}
This works especially great when using <ul> to create block sections or slideshows and you want the whole slide to be a link (instead of simply the text on the slide). In the case of an <li> it's not valid to wrap it with an <a> so you'd have to put the cover link inside the item and use CSS to expand it over the entire <li> block.
Do note that having it as the first child means it will make other links or buttons inside the text unreachable by clicks. If you want them to be clickable, then you'd have to make it the last child instead.
I have text that I would like to translate into Russian. The text has custom tags and has multiple <BR> tags. The API behaves oddly with <BR> tags. Are there known issues with <BR> tags? Is there a way around it or what is the best way to use Google JQuery tranlsation to translate the text?
The text is
<INPUTANSWER PARTID='1'>
<SPAN STYLE="FONT: 7pt 'Times New Roman'"> </SPAN>
Place a <STRONG>90 degree</STRONG> explicit angle constraint to the inside
faces of <STRONG>DP-1007:1 </STRONG>and<STRONG>DP-1006:1</STRONG> as shown.</P>
<P STYLE="MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in">
2.
<SPAN STYLE="FONT: 7pt 'Times New Roman'"> </SPAN>
Drive this angle constraint between <STRONG>90 and 100 degrees</STRONG>
with an <STRONG>increment</STRONG> <STRONG>of 0.125 degrees.</STRONG>
</INPUTANSWER>
check this. Its the jquery translate project. I've used it before with normal text, never tried markup but quoting their home page
It also reduces the number of requests by concatenating elements and doesn't send unnecessary html markup still providing access to each element as they've got translated.
If this doesn't work you can always hold on to the original document fragment and just walk it, translate content and replace. I am sure this will work as the API behaved perfectly with plain text.
Find traslator, who would read machine transltions, thats a bad tone. besides completely unclear from English to Russian due complete different language structures. Easier to read in English than auto translated text