I wrote a trivia game in Flex (flash). The site is written entirely in Flex. Almost all of the text is pulled from a database. It also has a fair number of images. The image file paths are pulled from the db.
My site's not getting any hits. If I check on google site:mysite it the url appears only. I know that inbound links are important and I'll try to get some. At the moment, I don't have any inbound links. In google webmaster tools, if I look under the site's keywords, there are 0. My sites been up for about a month.
Any suggestions on how to improve this situation?
(I've seen a few people ask for help with Flash SEO and the comments tended to be of the "don't use Flash" variety-- which aren't too helpful if you've written something in Flex/Flash).
Thank you.
-Laxmidi
Check out this article: Read Here
SEO FLASH PROGRAMMING
My recommended Flash SEO method uses a
DIV with search-engine-accessible,
primary content, and an open source
Javascript function called swfobject()
to detect when browsers are capable of
viewing Flash. When an appropriate
version of Flash player is present,
the Javascript manipulates the page's
document object model (DOM) to replace
the primary content with the Flash
movie. Most search engine spiders
can't handle Flash, so they will elect
to view the primary content. The
primary content may contain links,
headings, styled text, images—anything
we can add to an ordinary HTML page.
With SEO copyediting and coding skills
applied to the primary content, Flash
becomes a non-issue.
Flash accessibility programming isn't
spamming, as long as the primary
content and the visible movie are
essentially the same. The World Wide
Web Consortium (W3C) Web Accessibility
Initiative (WAI) specifically states
that multimedia content should have an
alternative representation available.
Accessibility programming creates the
benefit of presenting visual
information without losing the
visitors and search engines who depend
upon textual content.
As of July 2007, I discussed this
method with Dan Crow of Google. He
warned that this programming method
could draw attention because of the
possibility for abuse. If you use this
method, make sure the alternative
content is a faithful representation
of the Flash content, and avoid
combining this with other coding
methods that could be abused. While
this SEO method is not abusive, it is
aggressive because there is a small
risk that the search engines could
mistakenly decide that the primary
content is a form of cloaking.
I would also create a sitemap and link to multiple keyword rich landing pages about your game with a link back to the game. The more content google has to bite into the better changes someone will find you.
You also need to market your site...just because you build it doesn't mean they will come. Use twitter, facebook and any other form of social media to get the word out. You may also try buying a few bucks worth of ad words to start the ball rolling.
The solution to only the url appearing in Google is probably as simple as adding a meta description tag.
http://www.google.com/support/webmasters/bin/answer.py?answer=79812
http://googlewebmastercentral.blogspot.com/2007/09/improve-snippets-with-meta-description.html
It would also probably be beneficial to provide a description or instructions for the trivia game in HTML alongside the Flex part of the website, if this is possible.
Related
Got a site with powerpoint presentations that the client wants embedded, the embedding is being done via google docs embed. I have been doing some accessibility testing, albeit not particularly in-depth but even with OS X screen reader it is not having any luck reading the slides. (I am aware slides are probably terrible for accessibility anyway). I can get the text content of the slides stripped out via the Google API, but I don't know if thats the best thing, to include it on the page below/above the iframe embed with one of the CSS tricks for hiding it from normal view?
I am aware of iframe title and aria-label but those seem to imply they are only to describe the contents of the iframe, which I am doing, but I need somewhere that can contain more text.
Has anyone got any good tips for the best way to deal with such things? Thanks!!
Embedding rich 3rd-party content in web pages poses many challenges.
When we put something like this in a web page, we typically think we're adding a bit of "content", but it often amounts to embedding a complex application; and the user interface, semantics, and presentation are outside of our control. In your case it's a presentation slide deck, but it could also be a Flash/Silverlight/Java applet, a slippy map, interactive SVG infographic, a 3D-panorama, virtual tour, zoomable image, chemical molecule viewer, or who-knows-what. (Note: I'm not familiar with the Google docs embed/API specifically, so most parts of my answer will address these rich content cases in general.)
Even if the embedded rich 3rd-party content/application is accessible today, there's no guarantee it will remain so after the 3rd-party system gets an update.
So what can you do? The safest thing might be to assume it's inaccessible, and consider the best way to provide an accessible alternative. The Web Content Accessibility Guidelines (WCAG) calls this a "conforming alternate version", and it sounds like you're already thinking along these lines.
An important caveat to all of this, is that the use of "conforming alternate versions" isn't considered ideal by many accessibility specialists. It's greatly preferred to make your main content accessible as you can.
Some relevant parts of WCAG:
Understanding conformance, especially the section about "Understanding Conforming Alternate Versions".
Technique G190: Providing a link adjacent to or associated with a non-conforming object that links to a conforming alternate version.
F19: Failure of Conformance Requirement 1 due to not providing a method for the user to find the alternative conforming version of a non-conforming Web page.
It's worth mentioning the 3rd-party content in your website's accessibility statement. Statement of Partial Conformance - Third Party Content offers guidance about that.
The crucial thing about conforming alternate versions, is that it's no use at all if the user isn't made aware of it, or isn't able to reach it.
Implementation-wise, there are a variety of approaches you might take. In many ways, providing an alternative for embedded rich content is similar to providing a long description of a complex image, or a transcript of a video. Have a look at these WAI tutorials for some ideas.
Web Accessibility Tutorials: Complex Images
Making Audio and Video Media Accessible: Where to Put Transcripts
I can get the text content of the slides stripped out via the Google API
It sounds like you're trying to automate the process. That's fine, but it might not give satisfactory results. Some things you should consider:
Is the text content alone going to be enough? Presentations often have images too. Did the author provide text alternatives for these images, and are they present in the text extracted via the API? If the author hasn't provided text alternatives for images in the slide deck, the text you get from the API won't be telling the whole story.
Not all text in slides carries the same weight. Some slides serve to introduce sections, some slides have headings. Does the text obtained from the API convey these relationships?
Lists are very commonly found in presentation. Does the text obtained from the API preserve this structure?
Slides sometimes contain links. Are these included in the text obtained from the API, so the links are available to everybody using the alternative version?
Slides sometimes contain tables and charts. How will the information in these be conveyed in your alterative version? Is the information included in the text obtained from the API?
Sometimes, presentation decks also contain rich 3rd-party embedded content themselves! A slide containing a video, or an animated GIF are examples of this. If so, you can find yourself with a much more complex challenge.
... and many other meaningful info and relationships. Quotations, code samples, etc.
If any of the above points give cause for concern, you will need to consider managing your alternative version manually.
The "conforming alternative version" has to conform to WCAG; if you just offer a choice of two non-conforming version, that doesn't satisfy WCAG.
include it on the page below/above the iframe embed with one of the CSS tricks for hiding it from normal view?
No, I wouldn't recommend that. I assume you're refering to visually-hidden text, using CSS utility classes such as .visually-hidden or .sr-only. It sounds like you're only thinking about screen reader users.
You need to offer the alternative version available to everybody, not just one group of users who you think will need it.
Many groups of users may experience difficulty using the rich 3rd-party embedded content. This includes people using the keyboard only, screen readers, magnifiers, speech control, switch access, or other tools. The conforming alternative version can be navigated like a normal web page though.
The 3rd-party content likely has a different visual style, and it may not be adaptable in the same way as the page it is embedded in. That can frustrate people who make use of browser zooming, text resizing, font preferences, reader mode, Windows high-contrast themes, viewport resizing, and other user-applied presentation changes. The conforming alternate version should be as adaptable as the rest of your site.
Rather than hiding the alternative version in a visually-hidden container, here are some other ways to present it. The first two are the simplest and most reliable.
Put it on the same page, just after the original content, visible to everybody.
Put it in a collapsible disclosure element just after the embedded content. A <details> element is an easy way to achieve this. This is useful if the alternative version is quite long.
Put it elsewhere on the same page, and tell users where to find it. An internal link can help here.
Put it on a separate page, with a link next to the embedded content. I'm less keen on this approach. Only use it if you can commit to maintaining both pages.
Provide a way for users to switch between the two versions. For example some buttons, or a tabbed UI. However, you must also ensure that the switching mechanism is accessible. That might mean a full-blown ARIA tabs implementation.
I am aware of iframe title and aria-label but those seem to imply they are only to describe the contents of the iframe
Giving the iFrame a useful name is important. It's also a useful mechanism to inform screen reader users that an alternative version is available. The WAI Complex Images tutorial linked above has some similar approaches. Example: <iframe title="Google Slides Presentation of FOO BAR BAZ. Link to text version follows this frame.">. This only helps screen reader users though; you still need to make the availability of the alternative version clear to everyone.
How committed are you to using Google Docs for displaying these slides?
Any accessibility enhancements that you'll be able to implement on Google Slides won't be very good.
One way around this whole thing is to offer PDF versions of the slides that have been fully-remediated for accessibility instead of using Google Slides. That would potentially be a single solution that could be accessible to all visitors. Going this route means that you wouldn't have multiple copies of the same slides to update, which could lead to a split in content if one gets updated and the other is forgotten.
If you're really set on having the slides embedded in the page, then you could offer both formats by applying aria-hidden to the embedded iframe and then hiding the PDF links from sighted users using CSS clip, or by positioning content off-screen.
I want to provide some very simple content to the user that describes how to use a web form.
This text could just as easily be written in HTML, however, convention among the content writers is to write all help text in Word, convert it to PDF, and then put a link to the PDF at the top of the web application.
Assuming that the PDFs are tagged and/or 508 compliant, does this practice present any accessibility concerns?
There are two issues posed with your question:
(1) PDF when it could be HTML
This requires the user to have software that reads PDF format.
This requires the PDF to be tagged and made accessible.
This interferes with usability and is problematic for some users, especially on mobile where the focus switch to a different (PDF reader) application looses focus on your web page or web browser.
(2) "breaking" accessibility
The accessibility of your web content is evaluated on its own merits: you certainly can have an accessible PDF but if your reasoning is your HTML does not need to be accessible because of that, you are not accessible and fail your end-users.
There is also a hidden use-case for accessibility or usability you might not consider: web crawlers and indexing. Users rely on web searching to find content and your PDF is not indexed to map to your web page content in most search engines, so users will not find the help they need.
Most reasonable people involved with Section 508 would likely agree it is not accessible, as it fails 1194.22(n): When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.
§1194.22 Web-based intranet and internet information and applications
It is possible to convert Word content to HTML, and you are always highly encouraged to write the content as web content, because there are sometimes issues we simply accessing, and opening PDFs depending on the device they are using.
But to answer your question: no, as long as your PDF is accessible. I'd suggest putting it through something like the accessibility audit tool if you have Adobe Acrobat. If you don't, you might give content creators a simple check list, such as:
does your image have alt text if needed? (consider a decision tree/flowchart, example)
are your headings marked properly using the built-in styles?
are your tables formatted correctly? also tables are not used for layout
You'll probably notice these are typical guidelines when writing web content, but also apply to documents (Word, pdf, etc.).
WCAG has a list of PDF Techniques that you also want to check, but generally if you make sure that everything is tagged/styled/marked properly in Word, it should save to PDF with the correct tags and such.
I am planning to build a website completely in Flex. All the contents will be static. No DB will be used. Unfortunately I am not building the website for PUMA or NIKE and so SEO is important. There is an overwhelming and confusing information out there about Flex and SEO.
The following is a piece of information I found on the web
" FLEX( Flash ) uses XML as a primary source of content, and XHTML is just a custom XML. The idea is to to use the HTML pages as XML content for the FLEX( Flash ) application. The XML can be read and indexed by the search engines, and it’s also the ideal content source for your FLEX( Flash ) application.' It goes on to explain how this can be done. Is this really that simple. "
Could someone give some credible links. SEO is important for me.
If I'm really worried about SEO, I'm not building my site using Flex, Flash or Silverlight. A large part of SEO comes from the search engines crawling the content on your site's pages and analyzing the links into and out of your site. When you create a site using Flash or Silverlight, you're making it a lot harder for search engines to crawl your content.
If you're determined to use Flex for your website, I would recommend reading:
Revisiting Deep Linking with Flex from Jonathon Campos's blog
How to make your hot new RIA friendly to search engines from Josh Tynjala
Search Engine Optimization Technology Center by Adobe Developer Connection (Lots of resources here)
You'll also want to make your URLs as SEO friendly as possible (ex. http://www.yoursite.com/articles/my-article-about-flex/).
I'm looking for best-practices for designing a site that with accessibility in mind. The site is going to have a lot of older and less-abled individuals visiting it, and I want to make it as friendly for them as possible. Is there a resource that describes all the right tags, and attributes to use?
There are many many resources depending on your goals.
Strongly suggest you start with:
Section 508 (US legislation, obviously US centric though)
W3C's Web Accessibility Initiative and Web Content Accessibility Guidelines
edit:
Forgot to mention that WCAG has come in for some considerable criticism which makes this guy's efforts very helpful.
Also wanted to add, from personal experience, to remember that WA doesn't mean "blind people with screen readers". There are all manner of access limitations which you have to think of as well: e.g. dexterity issues related to e.g. muscle control, unusual input devices, and simple screen magnification.
Good luck!
Here's a quick list I tend to follow
Ensure it uses clean XHTML markup ideally to AAA standards,
Try where possible to spilt HTML, CSS, Javascript into respective files,
Create different style sheets for print, screen, etc.,
Ensure you take into consideration colours and fonts for the hard of sight and colour blindness,
Try to only place the main navigation at the top of the code so that the actual content appears near the top of the code, this way people do not have to scroll to far to see the content especially if they are using a screen reader / low res,
If you do have a lot of navigation before the content then place a link near the top allowing users to skip to the content,
Ensure the very first link on the page is to a text-only / low graphics version of the site,
Ensure ALL pages and all Essential functionality will work without JavaScript turned on,
There are lots of plugins for firefox to assist with development including:
Web Developer
No Script
HTML Validator
Firebug
Ensure the page renders across all browsers including old ones even if that means it works though does not match design exactly.
Ensure HTML, CSS, JavaScript is kept to the minimum file size to aid downloading times e.g. Remove white space and blank lines,
Always use LABELS in forms and alt, title tags in links and images,
Only use Tables for tabular data and ensure data appropriately labelled,
Where possible do not use JavaScript to write content to a page but use CSS to hide it, that way is JavaScript is disabled or does not work properly then content will still appear,
Always ensure you use onkeypress as well as onclick events in JavaScript encase the user can not / is not using a mouse.
Finally if you have to use blank images on a page for tracking etc. then don't give them Alt tags. This is my own view and is one which is hotly debated on-line especially when 1x1px images used to be used for spacing. However as far as I see it, if you are using a screen reader then you don't what it reading out stupid comments for images it does not need to see.
Try looking at Wikipedia's article on Web Accessibility. It contains lots of links to various sources of information for different countries, which may be useful depending on your target audience. The W3C was one of the original standards, but has plenty of critics.
Among other things.. provide "alt" and "title" attributes for every "img" tag.
Get a text-only browser like lynx. If your site works in lynx, it's likely to work for people who need screen readers or have other handicaps. It's no substitute for looking up the regulations, but it's a quick and easy check.
For another perspective, see the Dutch Government Web Guidelines.
The government provides a standard called section 508 that lays out what makes a site compatible.
A good resource is found at W3C site: Web Content Accessibility Guidelines.
A few things to keep in mind:
have a CSS link on each page that easily allows the font size to be changed.
Visually try to have appropriate presentation that is easy to read in a backwards S fashion.. left to right, back down.. etc..
ensuring that all the alt tags, etc, as mentioned in the other responses is vital.
see if there are some disability websites out there that specialize in testing your site. no harm in seeing what they list as being important to do.
make sure things are easy to read and find. this alone will make the job much easier.
There are many many resources on this topic. In fact, the danger is of information overload, rather than not enough information.
But an alternative approach is to think about your HTML page in generic terms, rather than the visual output you see in the web browser. If you wrote a piece of software that interpreted the website what would be helpful? This is a round-about way of saying use good semantics. My top tips would be to use standard XHTML for content and CSS for design. Also look up topics such as "progressive enhancement" and "behavioral Javascript".
But for resources:
The W3C's Web Accessibility Initiative: www.w3.org/wai
www.WebAIM.org
www.Accessify.com
www.CSSZenGarden.com for inspiration on how semantic markup can be styled to look very different.
It hasn't been mentioned yet so I figure I would mention it. If you want blind users to be able to use your site avoid flash. At the most 1% of flash I find on the internet is accessible.
A good list of resources about accessibility (colourblind screen-reader,typography etc) is here in design way.
For validation of web site and general documentation I use the W3C.
If you're developing in asp.net the opensource NAAK tool might be useful.
A must read is Jeffery Zeldman's "Designing with Web Standards"
Not sure if you are using Dreamweaver, but he has also just realeased a toolkit to validate your site for accessiblity.
How would you make the contents of Flex RIA applications accessible to Google, so that Google can index the content and shows links to the right items in your Flex RIA. Consider a online shop, created in Flex, where the offered items shall be indexed by Google. Then a link on Google should open the corresponding product in the RIA.
Currently the best technique for making an RIA indexable by search engines is called progressive enhancement (or graceful degradation, depending on which way you see it). Basically you create a simple HTML version of the application using the same data as the application loads. This version should be dynamically generated by some kind of backend server technology. This HTML version can be indexed by Google, but each page also contains a check that determines if the visitor is capable of viewing the rich version, and if so replaces the HTML content with the Flash, Flex or Silverlight application, preferably in such a way that the application starts in a state where it shows the same data as the current page. "Replaces" can mean that it just embeds the application on top of the HTML content, or that it redirects the user to a page that embeds it. The former solution is preferable, because the latter can be considered cloaking.
One way of keeping the HTML and RIA versions of a shop synchronized is to decide on a URL scheme and make sure that RIA uses some kind of deep linking technique. If a visitor arrives to a specific item via a search engine, say /items/345 the corresponding pseudo-URL in the RIA should be the same, so that you can embed the RIA on top of the page and set that URL as a parameter to make the RIA display that same page as soon as it has loaded.
This summer, Google and Yahoo! announced that they would begin using a custom version of Flash Player to index Flash based applications by exploring them "in the same way that a person would". Now, two months later there is still no evidence that this is actually happening. Ryan Stweart had to cancel his Flex SEO competition because it became evident that no one could win. The problem seems to be that event though the technique may very well work (although I'm sceptical), the custom Flash Player needs some kind of network interface to be able to load any referenced resources, like XML data, other SWFs, etc., and this is currently not implemented by Google. This means that for an application that loads all it's data dynamically, like say, all that I can think of, Googlebot will not actually see anything relevant. Yahoo! ignores SWF based content altogether.
Oh, and it just so happens that I talk about Flex and SEO on the latest episode of the Flex show =)
There is a massive thread available here:
http://tech.groups.yahoo.com/group/flexcoders/message/58926
But essentially, google already indexes .SWF files (you can test this out yourself by restricting search results to just .SWF files). It can search any text content within the SWF file.
However, if the text information in your site comes from a database / web server. Then it won't be able to access this information easily.
One example of getting this to work is using an XML file as your index page, then using an XSLT transform to render it using Flex. "Ted On Flex" has good information about this.
http://flex.org/consultants