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.
A client asked me about using Vuforia in order to recognize logos on the shop windows. Basically, they want to use logos as a QR.
Is this idea viable? Will it work pretty well? Can you tell my some alternatives to Vuforia about this?
Recognizing logos is hard.
Basically all image recognition algorithms rely on the same principle: trying to recognize "interest points" of the image. These interest points can for example be blobs or corners; in short, we want to look for places in an image where "things happen", compared to (for example) a large solid area painted in the same color where there is not much information to grab.
This comes to trying to recognize discriminant "details" of the image.
When applied to logos, this method tends to fail due to the fact that logos often don't have enough of such "details". Take the Nike logo for example: if corner detection is applied to it, it will only find 2 corners (the 2 ends of the accent). Blob detection will probably give no result at all. This is an extreme example, as the Nike logo is really simple, but even on more complex logos there will often not be enough details for recognition to work.
As for Vuforia: it works in this exact same way, and their web interface (Vuforia Target Manager) is very clear about it: when you upload an image on it for recognition, if there are not enough details on it, it will either warn you that results may be poor or simply reject the image.
To conclude: you can run some tests, it's still the best way to be sure of it, but I wouldn't expect great results. It will probably work for detailed logos, and fail on simpler ones.
Hope this helps!
I am a newbie learning to use graphviz.
Is it possible to generate interactive pop-out annotations when you move cursor around the graph? For example, hovering a node/edge will pop-out message box showing more information about it.
And if so, how?
Thank you so much for the help.
Depending on the output format, there are some possibilities:
You may create a png image and an image map and serve it as a html page. The world of html and javascript offers endless possibilities to make this interactive, use popout messages, etc.
If you prefer svg, some information is already included in the output as <title>, and again, if served within a browser, javascript may prove useful to enrich the output (not sure if it's possible to use existing svg with raphaeljs, but it sure shows nicely what's possible with svg + javascript).
You may simply have graphviz render the positions of all nodes and parse it's output to present it in your custom application
I am working on an ASP.Net web application that must print dynamically created labels on standard Avery-style label sheets (one particular size, so only one overall layout). The labels have a variable number of lines (3-6) and may contain either lines of text or a graphic barcode image.
Our first cut, that I inherited, used monospaced fonts to reduce the formatting issues, but that did not allow enough text to the fit on the labels and the customer was dissatisfied. Basically it was formatted text.
My next version used TABLEs, DIVs, CSS, and a bit of JavaScript calculations to format the labels using proportional fonts. It still required a bit of tweaking (the user had to set their print margins correctly and turn off the print headers and footers), but it seemed to work.
However, it seems that there are some variations on how different printers render the text (WYS ain't WYG), so even though we tested on different browsers using at least two different printers (an inkjet and a laser printer), some user's labels don't line up. Slight margin variations can be adjusted by adjusting the margins on the page setup dialog, but the harder problem is that the inter-label spacing can be off by a tiny fraction of an inch, so that if the first label is pretty well centered, by the end of the page the label text and images have crawled off the top or bottom of the labels.
We are about to the point of switching to generating Word, Excel, or PDF output which is going to take quite a bit of development time and possible add extra steps in the printing process.
So, does anyone have any suggestions on how to do an HTML/CSS layout that will precisely render on different types of printers? I don't really care if the line/word breaks are a bit different, but I need to be able to predictably position the upper left corners of each label area.
Right now the labels flow down the page in a table and we have been tweaking the box model of the cells and internal DIVs to make them a uniform height. I suspect that using absolute positioning of each element may be the best answer, but that is going to be tricky as well due to the ASP.Net generation of the label elements. If I knew for sure that would work, I would rather try it than throw away everything we have to go to a different generation method.
Slight Update:
Right now I'm doing some tests with absolute positioning - setting only the top and left coordinate of a containing block element. So far there are minor variations on the offset onto the page (margins, paper alignment, etc.), but all browsers and printers tested put the elements in exactly the right spots relative to each other. I appreciate the PDF tips, but does anyone know of additional "gotchas" on using absolute positioning this way?
Update:
For the record, I rewrote the label printing portion using iTextSharp and it works perfectly - definitely the way to do this in the future...
Forget HTML and make a PDF. HTML printing is extremely variable - not just across browsers but across different versions of the same browser. PDF is a lot easier.
Even if you get it exactly right with one browser / font setup / printer / phase of the moon, it will be the most fragile thing you've ever had to maintain. No matter how long you think it will take to make a PDF (and it's not really that hard as there are some free libraries out there), HTML will ultimately take a lot more of your time. PDF readers are widely deployed and print more consistently than even Word files.
The web is not a format that is guaranteed to get consistent print results. Given the standard support for label printing with MS Word, and the relative ease of automation and generation, I would strongly recommend going that route.
I'm not aware of ANY method to get percise printing across all types of browsers, operating systems, and printers when using web content.
"precisely" and "printing" aren't two words that really work together that well. I did an OCR/OMR application a year or so ago, and even when building a PDF I saw significant differences between different print drivers and such. Because of that, my gut is to tell you that you might not have 100% success.
If CSS and layout issues don't work that well for you, you might need to resort to building the labels as images using GDI+ -- at least that way you can use GetFontMetrics() and such.
Good luck!
I had a similiar issue and the answer is you can't do it. Instead, I generated a PDF file in realtime using iTextSharp and passed that to the response.
Using SQL Server Reporting Services, I generate a PDF to send to the printer, but it can be seen as HTML on the screen using the control you can include in your web pages. There are RDLC files that are available on the internet to print to various Avery formats.
I rewrote the SharpPDFLabel code that was mentioned back in 2011 this week as I needed it to be a lot more flexible (and to work with the current iTextSharp library).
You can get it here:
https://github.com/finalcut/SharpPDFLabel
I added the ability to specify the contents of each individual label if you want (or to continue creating a sheet of identical labels too). By extending the LabelDefinition class you can specify the layout of your labels pretty easily.
I also struggled with the HTML/CSS approach due to the inconsistent printing behaviour across browsers.
I created a C# library to produce Avery Labels from ASP.NET which I hope you might find useful:
https://github.com/wheelibin/SharpPDFLabel#readme
You can add images and text to the labels, and it's easy to define more labels types.
(I use it for barcode labels, the barcode is generated as an image and then added to the label using this library.)
Cheers
Add a few options to your app that let users adjust spacing for their particular configuration. You could include this right on the label if you want, and style it away via media selectors, but you'll probably want to persist them somewhere, too.
Flash is also good method to push a printable like a label albeit a little more complex to implement and maintain. In most cases it displays much quicker than a PDF and you can embed it into the design of the page and simply add a "Print" button within the flash.
I did this several years ago when we were using HTML and PDF to generate confirmation receipts. HTML is "ok" but is at the mercy of the end users web browser so we quickly dumped that method. PDF's are good as long as they have a PDF reader, which to our surprise a lot of our customers did not. So that was dumped as well after we switched to a FLASH version using a simple flash movie that included a few dynamic text areas and a "print" button. I communicated the data between the page and flash using a few flash vars. You can also use web service.
When I need something more than just simple text I use the free community edition of the PDF Generator component from DynamicPDF.com. It works great and is very quick.
I just went through the same thing. Ended up switching and making a short little JSF app (running on Glassfish) that uses JasperReports to print directly to the lable printer. Push button, instant label at the printer, don't even have to view it on-screen if you don't want to since Jasper can directly output to printer (as well as PDF in browser).
I was listening to a recent episode of Hanselminutes where Scott Hanselman was discussing accessibility in web applications and it got me thinking about accessibility in my own applications.
We all understand the importance of semantic markup in our web applications as it relates to accessibility but what about other simple enhancements that can be made to improve the user experience for disabled users?
In the episode, there were a number of times where I slapped my forehead and said "Of course! Why haven't I done that?" In particular, Scott talked about a website that placed a hidden link at the top of a web page that said "skip to main content". The link will only be visible to people using screen readers and it allows their screen reader to jump past menus and other secondary content. It's such an obvious improvement yet it's easy not to think of it.
There is more to accessibility and the overall user experience than simply creating valid XHTML and calling it a day.
What are some of your simple tricks for improving the user experience for the vision impaired?
Creating accessible pages is something that is hard to think about if you have never done it. However, once you learn the basic concepts it is very easy to do in 95% of the cases. I will mostly be repeating what others have said, but:
Only use tables for tabular data
Make sure you use the semantic tools available to you via HTML. This means using TH with a scope attribute. Use <em> instead of <i> and <strong> instead of <b>. Use the acronym and abbrev tags. Use definition lists. I can expand on these things if anyone wishes.
One of the most important things is to use the label tag on input fields. For every input field, radio button, checkbox and textinput you should have:
<label for="username">Username:</label><input name="username" />
Add a "skip navigation" or "skip to navigation" depending on where big chunks of text are. If you are working on a government site this should be second nature that everything you're creating allows you to skip repetitive information.
Do not use colors for emphasis.
Ensure that all of your text is resizable. This pretty much means don't use "px" in your css.
I will re-emphasize this: create semantic pages. Use H tags for your titles. Use ul/li for navigation.
Use the alt attribute on all images. If you have a spacer gif... well.. don't. Otherwise, explain what the picture is of and what its significance is to the content it is associated with. don't use "a chart" as your alt tag. Use "Chart of YTD finances: $5,000 Q1, $4,000 Q2, $8,000 Q3" or something similar.
Provide closed captioning or transcripts for all audio and video components
The key here is to provide those with visual, hearing and motor impairments the same experience as those with standard physical capabilities. If you can't tab into a field, a screen reader can't either. If you can't click on the text next to a check box to select it, the screen reader doesn't know the text is related to the check box.
You should frequently view your site without stylesheets (ctrl-shift-s if you have Firefox and the Web Developer Toolbar) to see if the page makes sense. If it doesn't make sense to you as a sighted individual, it won't make sense to someone using a screen reader.
Check out Fangs
Fangs is an in-browser tool for Firefox that emulates what a screen reader “sees” when visiting a Web page. Its function is simple: to output a transcript of what a screen reader will read out to a user when a Web page is visited. It’s a helpful tool for quickly analyzing if you’ve structured your content effectively so that it’s understandable and usable by vision-impaired individuals, without forcing you to learn to use (and purchase) a screen-reader application such as JAWS or Windows Eyes.
It's been awhile since I've been at a job where we had to adhere to Section 508, but here's what I remember that hasn't been touched on by the other posters...
Only use tables for data. Do not use tables for layout if you can avoid it.
When using tables for data, your column headers should be nested in TH tags and you should use title and scope attributes. Your table tags should use the summary attribute.
Images should all have a value for the alt attribute that describes what's going on in the image and if the image serves no purpose (it's a shim image or something similar) then the alt attribute should be set to empty string.
Try using a text to speech reader and/or navigate only through the keyboard and/or turn off stylesheets. I believe you need to purchase JAWS, but I'm sure there are free screen readers out there. You need to experience a site through a screen reader to truly understand how difficult most web pages are to navigate without the cues that screen readers interpret.
"Vision impaired" includes colour-blindness. I used to work with someone who couldn't distinguish red from green too well, so any applications that used a traffic-light style interface was very difficult for him to use. In the industry we were working in, alerts in rows were colour-coded, so another form of display was useful for him, such as an extra column in the row with the text of the alert type ("emergency", "warning" etc).
Biggest problem with screen readers is usually tables to position things on your page. Screenreaders can't really handle those. Put stuff in div's in your html and put them in a sensible order. Then position the div's on your page with css. Use tables to display content that should be in a table.
The code for many web pages is structured as:
Header
Top Navigation
Left Navigation
Content
Footer
When structured this way, then the hidden link for "Skip to Main Content" is beneficial. However, with CSS layout, you may be able to reorder this so that you have:
Content
Header
Top Navigation
Left Navigation
Footer
You then use CSS positioning and floats to move these different elements around on the screen to make the page look the way you want it to look.
The main advantage to structuring a web page in this way is that if the browser doesn't support the CSS, then the content is first on the page. In addition to screen readers, this is beneficial for mobile devices and search engine spiders.
For partially partially sighted we need to make sure text is not excessivly small and contrasts the background color substantially. We should also make sure text is resizable by using relative sizing units such as em's rather than absolute units like px's (although, in my opinion, this is becoming less of an issue as browsers are increasingly favoring zooming over text resizing).
For users of screen readers, it's helpful to get a good idea of the way screen readers are actualy used. The following article presents guidlines based on observations of blind people browsing the web using screen readers; it's a little out of date now, but gives you a good feel for what will help screen reader users, and what won't:
http://redish.net/content/papers/interactions.html
Additionally, the American Foundation for the blind have a section of their website dedicated to advice for web developers on how to cater for vision impaired users.
In addition to the visually impared, we need to consider those with disabilities that prevent them from using a mouse, and also those with neurological disabilities. If anyone can provide resources giving advice on how to cater for those individuals, that would be great.