How can we add blank alt tags to the Google map tiles (generated by v3 api) so that they do not lower our accessibility score?
It would be unwise to attempt to do what you are suggesting. By attempting to "improve" the score that your automated tool is giving you, you would almost certainly be degrading accessibility for actual humans.
The issue here is that embedded Google Maps are not accessible for non-sighted visitors, full-stop. Doing hacky things with JavaScript won't fix that. To the best of my knowledge, none of the major interactive maps are very accessible. Here are a few of the reasons why.
If you genuinely are concerned about the accessibility of your webpage, and not just an arbitrary number that some tool gives you, then there are a few things you can do:
Understand that non-sighted visitors won't be able to use interactive maps. Offer alternatives instead, like text directions. Clearly state any relevant addresses in the text of the page.
If your page contains embedded maps, you may wish to hide that content from screen reader users with the aria-hidden attribute.
The Google Maps web interface offers a reasonably OK level of accessibility when it comes to directions between two points. The directions URLs are of the format: https://www.google.com/maps/dir/?api=1&destination=Rockefeller+Plaza,+New+York,+NY+10111.
Use techniques that make use of special markup that is only announced to screen reader users.
Keep in mind that you are creating webpages for actual humans, not robots.
Test your pages using free tools, like NVDA or VoiceOver with more than one browser.
Related
There are some cases when you want to get a most representative image
of a web page, e.g. Pocket would try to add an image when you collect
a web page.
How would you define, in a programmatic way, which image is the key
image?
What would be the most appropriate way to do so?
Most websites that are seeking to be shared on sites like Facebook or Pocket will have an Open Graph protocol image. This is often an image in the head tag that uses the format <meta property="og:image" content="http://URL-TO-YOUR-IMAGE" />. The Open Graph protocol is used and looked for by companies such as Facebook, Pocket, Reddit, and has become fairly widespread in use.
For websites that do not follow such a standard, developers will often use a third-party tool such as Embedly, which has already solved the problem. Simply feed it a URL and it will return you some information on what content would be good for your thumbnail-ified images.
If you're wanting to create your own engine, you may want to study into DOM positioning analytics, and try to find your own algorithm by scraping many, many articles and web pages to try and find good patterns.
Study scraper.py to see how reddit uses BeautifulSoup to find representative images from links submitted to it.
How can we add blank alt tags to the Google map tiles (generated by v3 api) so that they do not lower our accessibility score?
http://berkeley.edu/map/googlemap/
Couldn't let this 1 go
You can use the tilesloaded event then use jQuery to modify the images post render
google.maps.event.addListener(this.map, 'tilesloaded', function(evt){
$(this.getDiv()).find("img").each(function(i, eimg){
if(!eimg.alt || eimg.alt ===""){
eimg.alt = "Google Maps Image";
}
});
});
It's not at clear that adding ALT to content that is inherently graphical is going to do much good from an actual accessibility point of view. Stepping back a bit:
What tool are you using to generate this score?
Do you care about some tool-generated score for some mandated compliance reason, or is the real goal here to make your pages actually accessible?
And how are you using the tiles? Is this on a set of pages that you yourself own?
The goal here really should be accessibility, not compliance as measured by a tool; tools are supposed to help with this task, but unfortunately there are many cases where tools measure adherence to some set of rules, but cannot measure accessibility itself. For example, a tool can determine whether an image has an ALT attribute; but the ALT attribute has to be present and meaningful in order for the image to be actually accessible. So try to think about the bigger picture - keeping the users happy - not just about trying to keep the tool happy.
If you are displaying these tiles in your own set of pages, your best bet might be to have text somewhere else on the page that explains what's going on in the image. For example, if it's a map providing directions to some place, provide textual directions alongside.
The right solution here really depends on what you want to use the images for - can you provide more details on what the larger project is here?
Once you've got some accessible alternative to the graphical tiles in place, your best bet for handling the actual IMG tiles might be to set alt="", which tells a screenreader to ignore them outright; this is likely the best course of action here since having a screenreader read out "image, image, image..." isn't going to be particularly helpful.
--
Assuming that you're talking specifically about the Berkeley Campus Map at http://berkeley.edu/map/googlemap/ - that's an interesting case. There's a list of buildings along the left edge, and a map in the main part of the page. Click a building, and a pin appears with a popup with some information and a more link, click that more link and a lightbox appears with more detailed information.
One issue that I see here is that when a screenreader user clicks one of the links on the left side, they may not know that a popup has appeared with more information elsewhere on the page. Even if you know there's a popup there, you'd then have to navigate over the intermediate links to get to its content, which would be somewhat awkward. (Hiding the images with alt="" at least means that they don't have to navigate over all of those.)
Perhaps moving the focus into the popup would help here (screenreaders generally follow where focus goes), but that might be tricky if the popup is managed by Google Maps code. And this is likely something that would need to be tested with a real-world screenreader such as the free NVDA on a PC or VoiceOver on a Mac - and even better, verified with a real-world screenreader user!
At this point, we're now getting deep into the specifics of that particular page, which might be out of scope for this answer, but it really does help make the point that for situations like these, you have to look at accessibility at a page-level issue (directory of campus buildings) rather than just looking at one problematic component (IMG elements) in isolation.
I work for a company (Deque Systems) that creates an Enterprise scanning engine that generates an accessibility score for each page and each project. My recommendation is to use that as a very rough guide ONLY and to instead focus your efforts on making sure your site is really accessible. Automated testing tools can only catch 30% - 50% of accessibility issues.
In terms of a "more accessible" Google maps - take a look at this "accessible" version of Google maps I created. It does more than simply add alt attributes to the image tiles. It also adds focus styles (albeit ugly ones) to the focusable elements and adds accessible names to the controls where these are missing. Note that it is language dependent and my implementation only works for English and German.
I ended up using javascript to add the alt tags. Please note the map id is unique to my specific map.
google.maps.event.addListener(this.map, 'tilesloaded', function() {
var images = document.querySelectorAll('#gmap_canvas1 img');
images.forEach(function(image) {
image.alt = "Google Maps Image";
});
});
iGoogle's standard RSS feed gadget is not OpenSocial, so it can't be embedded in other web sites. So I am hoping there is an alternative solution already available somewhere.
In iGoogle's gadget list there are other RSS gadgets, but none of them seem as nice as the default one by Google which is native to iGoogle.
The main difference between the standard gadget and most others is the ability to expand a headline and see more of the article by clicking the arrow next to the story. Also a clean layout.
It must be a widget/gadget that is OpenSocial compatible.
(I am aware that iGoogle will be closing, that is not relevant to my needs.)
MyYahoo:
Appears overall best alternative to iGoogle in terms of setup speed, "just working", and widgets for average or novice users.
appears not to import opml, but can support rss feeds
by hand can setup the same rss feeds as igoogle or netvibes
supports upto 9 tabs. every tab has an advertisement
only supports Yahoo search
appears no wikipedia search widget
good support for display of stock portfolio quotes in widgets provided by Yahoo
several good yahoo widgets provided, e.g. tv guide, local movies
can have different theme for each tab, or all the same.
can use uploaded image for wallpaper.
can make backgrounds transparent.
can set background and text colors for all parts of a theme, separately.
has spectrum chooser for colors. cannot type in hex codes.
very user friendly interface for configuring themes.
supports user-created applications (widgets) for MyYahoo tabs.
This is how to get started with it
Try Skim.Me as an alternative to embedding iGoogle's RSS gadget
We have a hybrid slideshow, meaning, each slide has its own unique URL, yet you can click through the whole slideshow without refreshing the page. In order to achieve that, we have a JSON living on each unique URL with info of all other slides, such as headers, subheaders, captions and image URL's.
Would that affect SEO negatively? Would Google read the JSON? And if so, would they read it as redundant data?
At current, this "one-page" architecture will negatively impact your ability to rank on Google.
Here are two public perceptions of how Google handles javascript:
1) Google can crawl some content served with javascript however does not prioritize it as highly in SERPs (search engine results pages) as content served across plain html pages.
Some technologies like screen readers (used by the blind) do not process javascript effectively and limit applications of this nature from achieving penetration to greater than 95% of the internet-connected population.
2) Google can crawl javascript but they have not yet weighed it into their algorithm because their technology has not yet fully matured.
I personally am with the first camp and believe that javascript sites won't be considered as highly in SERPS until ancillary web-browsing technologies supporting niche population groups have excellent support for javascript.
Only time will tell :)
In recent versions of Safari, there is a "Reader" button that appears in the address bar on certain web pages. When you click this button, it will give you a text-only version of the article on the page without any ads or content that is not part of the article. I would like to create a web app that does something similar when the user enters the URL for an online article (a New York Times article, for instance).
I am wondering if anyone has any guesses as to whether this feature in Safari is implemented in:
A complex way, e.g. "grepping" through the article and following some algorithm to guess which tags to extract, etc.
A simple way, e.g. accessing some sort of RSS or Atom feed that provides only the article text. From what I can tell, most of these feeds seem to only provide short descriptions of articles and links to them, rather than the full text.
Any thoughts?
It's done in a complex way.
Read through this: How to enable iOS 5 Safari Reader on my website?