Does providing PDF content when it could be HTML break accessibility? - accessibility

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.

Related

WCAG 2.1 AA Compliance and User-Generated Content - what do you do with content that you don't control?

I am having trouble finding clear information regarding WCAG 2.1 compliance and user-generated content. Would a site fail compliance if the end users of the site created or uploaded content that would fail to conform to requirements?
Some examples could be the user uploading video content without captions or subtitles, or gifs that contain flashing content, or using a page editor to create different levels of html heading tags throughout the page for their personal preference but could interfere with screen reading technology etc...
What do you do about content which you cannot control?
You have two options - force users to upload WCAG compliant content (which is near impossible, but you can improve things by insisting on alt text, .srv or similar format caption files for videos etc. and explaining why it is important) or you use a statement of partial compliance on the site, of which their are two versions.
Statement of Partial Conformance - Third Party Content
The W3C recognises that you cannot control third party content, including user uploaded and user linked (embedded) content.
Now here you do have two realistic options, depending on your available resources.
Option 1 - maintain the pages
If the content is uploaded to your website then you have the option to "repair" it. You can put a system in place to monitor newly added content and add / adjust the markup, alt attributes etc. to make the page compliant.
You would still add a statement of partial compliance but would also state that pages will get updated and maintained to provide full compliance within 2 business days.
Due to the heavy resource requirements on busy sites this may or may not be an option.
However this would be the preference if you are able to do this (to reduce costs you can combine this with any mediation / approval processes you have in place. For content that cannot be made accessible, for example your scenario of flashing content, you can have a simple warning box that can be used to explain the problems with the content.)
Option 2 - accept that user content is not compliant
A "statement of partial conformance" may be made that the page does not conform, but could conform if certain parts were removed.
You detail which pages / page types are not compliant, but explain which parts are compliant and which parts need to be removed in order to make the page compliant.
I would put a warning before any content that explains that it is user generated content and link this to your partial compliance statement. It could have a positive effect where a few people take the time to learn about accessibility.
It must be noted that third-party implementation and third-party content are two distinct things:
Using a page editor that generate bad heading tags is on the author's control.
Permitting third-party users to add content to the website is not (but can be) on the author's control,
For instance, integrating a twitter feed written by your social media manager is on your control : appropriate image alternative and text can be made, and using the API instead of the iframe integration can provide sufficient accessibility.
If you let people upload a video without giving them the ability to provide captions, then it's on your responsibility. If they can choose their own provider (like Youtube) but do not provide captions, then it's their responsability.
See Partial conformance claims due to third party content
When an author makes a decision to use a third party implementation, they should choose products that meet WCAG requirements. [...] However, if the page does not conform to WCAG only for reasons that are legitimately outside the author's control then the author can make a claim of partial conformance. It is important to recognize that this is a statement of non-conformance

Accessibility with Google Slides Embed on a webpage

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.

Building a bespoke PDF brochure via web form or CMS

I'd like to set up a CMS that allows clients to generate a PDF brochure from a series of text inputs and text areas (rich text editor). Clients would fill out text inputs and then select (via a check box) which contents should appear in the exported PDF. This would then stitch together a PDF brochure containing pages only applicable to the options chosen by the client.
All the content is in a CMS with web pages and pdfs built on the fly as per the client's choices. A change in the content is then reflected immediately in the published docs meaning no redundant, out of date pdfs and the benefit of all the tools within the CMS (workflow, publishing dates, security, etc).
Does anyone know of any tools that do this?
Appreciate any help.
well your question require a lot of work to be done. I had similar requirement and what i have done i can brief here. I created multiple views which lets me select their columns and i have used my own rules for differentiating columns from test like {view.columnname}. when your save all information i have used itextsharp for pdf generation.
There is plenty of information on itextsharp.
You might be able to do this with design tools and reporting software, plugged into your CMS of choice. For example, you could use Wordpress, and then design your PDF output using iReport, and run it with Jasper. You'd have to work on the bit to translate user inputs to a query passed to the report, but that shouldn't be too much work.
One issue is that, regardless of the work you put into the design, when you attempt to share it, it wont look like a brochure at all, only sequential single page PDFs. As an alternative I found a website where you can upload or design your brochure, it can then be downloaded and shared as a flippable, digital brochure. If you are interested check out https://simplebooklet.com/learn/animated-tri-folds.php

Flex SEO & Google

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.

How to make Flex RIA contents accessible to search engines like Google?

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

Resources