One of the 508 compliance rules are that all OBJECT tags should contain element content. I'm not familiar with OBJECT tags or anything, but what should the content usually be? I noticed if I just put any string within the OBJECT tags I seem to pass the 508 test.
Is it acceptable to put anything within the OBJECT tags to make this pass verification? Can I just put "useless string"? What effect does the content have?
The content should provide information equivalent to the embedded object.
Using an useless string will not make it 508 compliant. Thus, that wouldn't be acceptable if your goal is 508 compliance. Your automated test may report a pass, but it's not really compliant unless it has real content.
The effect of this alternate content? When a disabled person visits the website and their assistive software cannot process the embedded object, the software falls back to the alternate content. Let's say you embed a Flash presentation in the page. When a blind person visits the site with a screen reading software, the screen reading software might not be able to parse the Flash movie. Instead, it reads out the text that is in the alternate content.
The content is for fallback in the case that the browser for any reason cannot display the object. Think of it as like the alt attribute for <img> elements. An automated checker can't verify that you are putting something sensible in, only that you've put something in.
It's your responsibility to make that content sensible. It should provide the best possible equivalent in text (or other HTML) that you can provide that conveys the same information as would have been conveyed by the object had it been displayable.
Related
Say I'm building a typical document editor:
Where the preview (in red) is an up-to-date, formatted vue of the form's data.
The preview element contains semantic elements (e.g. h1, h2, main, header, etc.). It's kind of a document in itself, which does make sense, conceptually. But this makes the structure of the real document quite confusing for crawlers and screen readers. There might be, for instance, two h1 or main elements. I'm looking for a way to avoid that.
Plus, there's the problem of repetitive content (see image).
For the accessibility part of the problem, I could just add an aria-hidden="true" attribute to the preview element. In fact, visually-impaired people don't need the preview, it's just redundancy to them, they just need the form.
But for crawlers, here are my options:
Don't use semantic elements inside the preview element, use divs instead (đ„).
Host the preview at an other URL and insert it via an iframe (that's what I'm doing right now, but it seems hacky to me).
Leave it like that, crawlers don't care.
Any idea/resource/suggestion?
As long as your preview area is clearly indicated for assistive technology, it's perfectly fine to have redundant information. If you have an <iframe>, make sure there's a title attribute on it.
<iframe title="preview area"...>
However, you might have validator issues with multiple structure elements.
For example, HTML only allows one <main> element:
A document must not have more than one main element that does not have the hidden attribute specified.
You can have multiple <header> elements but a <header> has a default role of banner and the banner role says:
Within any document or application, the author SHOULD mark no more than one element with the banner role.
The key here is "should", meaning it's a strong recommendation but not required. You can also get away with multiple banner roles if your preview section has role="document".
I would recommend not using non-semantic elements (div) because an assistive technology user might want to check the actual semantic structure of what's generated, although I suppose you could also have a "show in new tab" option for the preview that uses all full semantics, kind of like your second bullet but not using an iframe.
I am working on doing accessibility remediation to several websites based off WCAG 2.0 AA standards. These sites have quite a lot of links to PDFs. Here is a common example of what they have:
Get Blah Information
Based on my best understanding of WCAG 2.0 AA principles, this links should have title text added, becoming something like:
Get Blah Information
My question is about this title text. It only seems occasionally appropriate. Most browsers will open the target="_blank" in a new tab, not a new window. Also, on mobile many devices will launch a native app to open the PDF. Some devices/browsers will actually download the file, depending on the settings. With all these considerations, is there a better, more universal title for these types of files?
It's generally considered courteous to give people a heads-up that that what they are clicking on will not open up as a webpage.
In my organization, we require that PDF links (or any link pointing to a non-HTML document) needs to clearly annotate the file type in the anchor text.
Like this:
Get Blah Information (PDF)
The title attribute isn't consistently supported among screen-reader/browser combinations, so I wouldn't recommend depending on it to work.
Links to Non-HTML Resources
https://webaim.org/techniques/hypertext/hypertext_links#non_html
Users should generally be alerted to links that lead to non-HTML resources, such as PDF files, Word files, PowerPoint files, and so on. However, there is some debate as to whether the content author or the browser should be the one to alert the user. The trouble is that none of the browsers or screen readers currently alert the user at all, so the debate is more theoretical than practical.
If you're opposed to putting the filetype in the anchor text, you could always use the aria-label attribute to supplement the anchor text, or position the text off screen so that it's not visible to sighted users, although these solutions may be less accessible for users with limited-sight ability.
I would avoid using the title attribute in this case. There are several issues with its use, and it should be avoided in most cases. For example, screen reader software will often read the title attribute in addition to the text that is already in the link, thus reading redundant and potentially confusing text. The way that the title attribute is handled is inconsistent across assistive technology. Read more about when to use and not use the title attribute.
Additionally, I would avoid describing the action that will take place. As you described, different technology/devices handle the link in different ways, and the user can even choose how to interact with the link (open in a new tab, etc). Instead, focus on describing the purpose of the link. Your first example: Get Blah Information is much better than the second.
HTML5 introduced many semantic elements (<nav>, <section>, <article>, etc.). But aside from helping read and structure our HTML, do they have any other unique properties? Or are they essentially just <div>s with different names? It seems like the latter is true.
I keep reading about the "semantics" but can't find a direct answer.
The <nav>, <section>, <article>, etc., elements donât have any special properties that are exposed to frontend JavaScript code; instead they all just use the HTMLElement interface.
However, they do have special properties in screen readersâin that they get announced to screen-reader users in a special way that a div element doesnât.
Screen readers can announce that a certain part of a document is a section or article, and allow screen-reader users to navigate through the document section-by-section, or to more easily jump among articles.
That said, screen readers also enable users to easily navigate through a document by jumping among its h1-h6 headingsâregardless of whether those headings are in section or article elementsâso for screen-reader users itâs actually more important that your documents have good informative h1-h6 headings and a logical structure.
Semantic elements are elements that describe the content. They provide more information to the browser without requiring any extra attributes.
Considering Microformats
When youâre adding semantics into your web pages, you should consider using microformats to add even more meaning, when appropriate. Microformats use human-readable text inside the HTML (usually in the class attribute of an element) to define the contents.
Microformats add semantic information about the elements, and this information is already being used in certain situations.
Above figure shows a Google search for reviews of the movie Enderâs Game. The second and third results show ârich snippets,â including information like the star rating.
Google and Bing are both using these types of rich snippets to enhance their search results, and most of the data they are using to get it is semantically marked-up HTML using microformats. You can learn more about how to use microformats in my book Sams Teach Yourself HTML5 Mobile Application Development in 24 Hours.
By writing semantic HTML, you give more information to user agents to use to display the information correctly. For example, if a screen reader sees the element, it knows that this is the main point of the page, and it will read it aloud before reading anything in an element. Plus, as web pages get more and more sophisticated, what the user agents do with them gains sophistication. For instance, in the future, your semantically marked-up recipe could tell a web-ready refrigerator what time to alert the robot butler to start the roast.
I'm tasked with taking a website and making it so that the AInspector Sidebar evaluates to at least no WAI ARIA violations (preferably no warnings either).
There is a page that includes embedded Vimeo video(s). Included in the code that the iframe brings in is an element with the landmark role "contentinfo", which I am already using in the appropriate place on the website pages. So now I have a violation for duplicate landmark roles.
Is there a good way to solve this? I guess I could use the "old embed code" offered by Vimeo but I'd rather avoid that if at all possible. I've searched all over but can't find any guidelines or best practices for this sort of situation. Maybe I'm not using the right terms?
http://www.w3.org/TR/wai-aria/roles#contentinfo
While the spec does say
"Within any document or application, the author SHOULD mark no more
than one element with the contentinfo role."
it also says
"Note: Because document and application elements can be nested in the
DOM, they may have multiple contentinfo elements as DOM descendants,
assuming each of those is associated with different document nodes,
either by a DOM nesting (e.g., document within document) or by use of
the aria-owns attribute."
So perhaps if your iframe was a document or application, that would satisfy the tool. If not, then the tool might be interpreting the spec incorrectly.
OK, I know how to include HTML content from a separate file using the <object> tag. What I can't find any info about is what is allowed/required within the included HTML file. Can said included file merely be some text with some HTML tags, or does it have to be a complete HTML file with headers, <head>, and <body>? How does this appear within the DOM of the original document, if it appears within that DOM at all? Or are the two documents treated entirely separately?
Yes, I know, I could experiment to see what works. However, I know enough about HTML to know that what happens to work, for now, may not be the correct way to do things. I am not expecting anyone to list out all the rules here, but if someone could post some links I would much appreciate it. This is a topic that has proven exceeding difficult to search the internet for.
In 13.5 Notes on embedded documents, I believe I have found the answer to both of my questions. The second paragraph says,
An embedded document is entirely independent of the document in which
it is embedded. For instance, relative URIs within the embedded
document resolve according to the base URI of the embedded document,
not that of the main document. An embedded document is only rendered
within another document (e.g., in a subwindow); it remains otherwise
independent.
So, yes, as both #Quentin and #Sinan said, it would require the embedded .html file to be a complete, valid .html file. And, no, it would not become part of the DOM of the original document.
Thanks to everyone for their prompt assistance. The StackOverflow community continues to amaze me.
<object> is a way to include a generic media object.
An HTML document is an example of such.
The HTML spec doesn't describe a means to provide a fragment of HTML to a browser, only a complete document. There is no standard MIME type for a fragment of HTML.
Therefore: You should use complete HTML documents.
That said, if you are going down that route, you would almost certainly be better off using <iframe> which has a much more featureful and robust set of APIs and documentation surrounding it.
How does this appear within the DOM of the original document, if it appears within that DOM at all?
As an object element. The child nodes of which are whatever alternative content you provide between the start and end tag.
Or are the two documents treated entirely separately?
Yes, much like an iframe.
<object> in HTML5 and <object> in HTML4.
The object element represents external content, which, depending on the type of the content, will either be treated as an image, as a nested browsing context, or as external content to be processed by a plugin.
Motivation from HTML4:
Previous versions of HTML allowed authors to include images (via IMG) and applets (via APPLET). These elements have several limitations:
They fail to solve the more general problem of how to include new and future media types.
The APPLET element only works with Java-based applets. This element is deprecated in favor of OBJECT.
They pose accessibility problems.
To address these issues, HTML 4 introduces the OBJECT element, which offers an all-purpose solution to generic object inclusion. The OBJECT element allows HTML authors to specify everything required by an object for its presentation by a user agent: source code, initial values, and run-time data. In this specification, the term "object" is used to describe the things that people want to place in HTML documents; other commonly used terms for these things are: applets, plug-ins, media handlers, etc. (emphasis mine)
So, basically, <object> elements are pretty generic. The only real condition is that there needs to be some kind of functionality on the client side to render the element.
For example:
<object data="test.html" height="50" width="50"></object>
renders the contents of test.html in a tiny area (no scaling!) with Firefox whereas links just displays [OBJ].
Embedded Content explains what happens when an <object> element is encountered.
Due to the algorithm above, the contents of object elements act as fallback content, used only when referenced resources can't be shown (e.g. because it returned a 404 error). This allows multiple object elements to be nested inside each other, targeting multiple user agents with different capabilities, with the user agent picking the first one it supports. (emphasis mine)
I believe that answers the question of how the <object> enters the DOM. If it were any other way, for example, element ids in included documents could trample on the DOM of the host page.
Regardless of what capabilities you observe in current user agents, you should ensure included HTML documents are well-structured, and valid.
Further down, consider the included example:
In this example, an HTML page is embedded in another using the object element.
<figure>
<object data="clock.html"></object>
<figcaption>My HTML Clock</figcaption>
</figure>
Note the example refers to an HTML page â not a fragment.