I want to allow authors to enter long descriptions in the CKEditor image plug-in dialog, descriptions which then are available to screen readers via the aria-describedby attribute. In our use case, authors work in a WYSIWYG mode; they're not expected to edit raw HTML, so we can't ask them to enter an ID in the image dialog, add a corresponding ID to some other element, etc.
It's a trivial matter to enhance the CKEditor image plug-in dialog to have a field where the author can enter a long description to accompany the short alt description. The result could be something like <img data-long-description="this is a long description" alt="short description" />. But what we need is <img aria-describedby="longDescriptionID" alt="short description" />, where longDescriptionID is the ID of some element on the page (hidden from sighted users or not)....
I have a couple of possibilities in mind. (1) keep the image plug-in doing what it does: output an <img /> tag, as in the first example, and then some other code in the end user-facing view has the responsibility to find data-long-descriptions, replace them with IDs (randomly generated, say) in an aria-describedby attribute, and somewhere in the view insert corresponding content hidden from visual users, so that screen readers will pick it up.
Possibility (2) is to have the image plug-in output something like <span class="accessibleImage"><img aria-describedby="randomID1" alt="short description" /><span id="randomID1" class="accessibleLongDescription">This is nice, long description of the image blah blah blah</span></span>, where .accessibleLongDescription is hidden except to screen readers.
It's good that you're looking into this. More detailed descriptions for images are often useful. A couple of thoughts...
It isn't just people who use screen readers that find longer descriptions useful. People with cognitive disabilities will often benefit from more detailed explanations of complex images. If you can make the descriptions available on demand to anyone, this will help more people.
When the description is inserted into the DOM it needs to be immediately after the image it relates to. Screen readers use a translation of the DOM known as the accessibility tree to access content, so DOM order is important.
So one possibility is to combine your methods - search/replace the data attribute as you suggest in your first method, then insert the description based on the pattern in your second method.
Another possibility might be to use a disclosure widget pattern instead. Represent the image as the trigger control for the disclosure, and make the detailed description available when the widget is expanded.
A reasonable disclosure widget pattern is here.
Related
I have a header tag that contains the title of the page. The Windows screen reader is not reading that text and i wanted to know if there is a way to do so by adding some aria items?
<section class="section">
<header class="section-title" ip-l10n="county_list">List of Countries</header>
</section>
Just to make sure we're talking about the same thing, there are headings and headers. Headings are <h1> through <h6> elements. Headers are typically used when describing tables and are the names at the top of the column, the column header or <th> tag.
You had mentioned that your header contained the "title of the page". The title of the page is normally contained in a heading, specifically an <h1> if it's the main title of the page. So I wasn't clear which term you were really asking about.
I know your example used the <header> element so I will limit my comments to just that element, but I did want to point out the aforementioned differences to make sure we're all talking about the same thing. Accessibility and aria tags are all about semantics so it's good to be clear about the semantics of your question.
The <header> element is a container for stuff that's usually at the top of your page. By default, it creates a banner landmark. A <header> usually contains a <nav> which is the main navigation for the site that is repeated on all pages. It might also contain the company logo as an image and serves as a link back to the home page. It might also have account info, or if a retail site, the shopping cart contents. So a <header> might have interactive and non-interactive things.
In your example code, you just have plain text in your header. That's not interactive so a screen reader user will not hear the text if they are using the tab key to navigate the site. They will hear the text if they navigate the DOM using the up/down arrow keys with the screen reader.
If instead, you really meant for your code to be a heading, and thus the <h1> tag, that is also static text that is not interactive so again, the screen reader user will not hear the text if they are using the tab key to navigate the site. However, they can hear the text if they use the screen reader H quicknav key (to navigate to a heading).
So if you want to clarify your question, I can update my answer.
I've inherited a project that uses a lot of click-triggered JS to change page content instead of linking to different actual HTML pages. I'm being asked to make JAWS read the page title when this happens, as if a new page is being loaded.
From my observations and a bit of light testing, reading the page title (meaning the contents of the <title> tag) is standard behavior for JAWS when linking to a new, separate page (as in a foo.html file), but not what happens when a same-page link or button is clicked.
How can I cause JAWS to read a page's title after a link or button is clicked that changes the existing page's content in a way that seems like a new page to the user but is actually the same file under the hood?
For this question, please assume that refactoring what I have to use an actual new page instead of JS content replacement is not an option. And if something is wrong with my initial assumptions, please let me know that as well.
It sounds like you have a single page app (SPA). You can't force the <title> element itself to be read but if you also put the same text into an aria-live="polite" container (a visually hidden <div> or <span> (*)), it'll be read.
You still want to update the title, even if it's not read, because the screen reader user can use a shortcut key (INS+T with jaws) to read the page title. And when the user switches between the browser and another app and then back again, they'll hear the title, so it's still important to update the title.
There are some decent blogs regarding accessible SPAs:
Accessible page titles in a Single Page App talks specifically
about the page title in SPAs
Building Accessible Single Page
Apps talks about general principles but doesn't really have any
code examples
Single page applications, Angular.js and accessibility talks specifically about using angular but the concepts and code examples can be applied generically.
(*) Note, when visually hiding the aria-live region, don't use CSS display:none because that'll hide it from the screen reader too. Use a sr-only type class. See What is sr-only in Bootstrap 3?
There's good info in slugolicious's answer. The specific issue has a simpler solution, though: <title> elements can be ARIA-ified.
<title role="banner" aria-live="polite">Default title here</title>
in conjunction with
$(function() {
// existing logic here
$(title).html("New title here");
});
being called when the new content loads.
I'm 'scraping' a few product descriptions from a website and bringing them into a google spreadsheet using importXML.
It has gone fairly smoothly, but there is one major snag that I would love to correct, and I need your help!
The website in question prohibits those posting products from including contact information (email addresses usually) in the product description. Sometimes people ignore the rule, and include the contact information anyways. When this occurs, the website automatically hides the contact information in the product description, replacing it with [obscured], as in "...please feel free to contact me at [obscured]" or something close to that. The [obscured] appears in a different colour, and is obviously treated differently by the website.
When these product descriptions are imported into my spreadsheet, the [obscured] causes the scraping to kind of be 'bumped'-- the description text stops prior to [obscured], the word [obscured] appears in an adjacent cell all by itself, and the description text that follows [obscured] then continues in a third cell.
This separation ruins the alignment and logic in my spreadsheet, as product descriptions having an [obscured] word become broken up and misaligned from those that do not.
I would love to be able to have my importXML or XPath accommodate for this, and essentially 'ignore' the [obscured]. I don't mind it being included in the scraped description, but I want to stop the breaking-up into 3 separate adjacent cells.
The [obscured] is part of a 'span' that appears to occasionally lie within the description class 'desc' I am calling.
Is there a way to do this? Instruct importXML to import that 'desc' class BUT 'ignore/omit/exception' of the span which might sometimes appear within?
I've included the source code (inspect element in Safari) below:
<div class="desc descFull collapsed">
<span class="obscureText">[obscured]</span>
As mentioned, this span only occurs in some of the product descriptions, not all of them.
Does anyone know what kind of language I would use in the importXML to call the 'desc' but ignore the 'span', or prevent the splitting into 3 cells when the [obscured] is encountered??
My current call is
=ImportXML(A1,"//div[#class='desc']")
which works fine, unless the [obscured] span is encountered.
Thank you for any help you can give!
Unless Google Drive is breaking the definition of Xpath, Xpaths can't be used to query CSS classes, like CSS selectors can.
The Xpath //div[#class='desc'] will only match a div element with a class attribute that is literally "desc". It won't match "desc descFull collapsed" as the string is different.
As for excluding the text of the obscured node, that would require finding the text nodes and exluding on, which would return a nodeset, not a string, and you wouldn't be able to concatenate these back together using XPath 1.0. If Google Drive uses XPath 2.0 it might be possible, using the techniques in that linked question.
I have a website with newspapers frontpages so pages contain only big images and no text (neither description, because images change daily).
What's the best way to insert context keywords in the pages?
Is correct insert in body only keywords without link?
if you can change image names put keywords in those & also use related words, synonyms, plural / singular
also add alt & title attributes
Even though your pages do not have any content (only images), you still can provide proper page descriptions which will be used by Google (and other search engines).
A couple of handy tips:
Create unique, accurate page titles using <title> tag placed within the <head> tag.
Please bear in mind that Google does not recommend putting keywords into the title tag. So it is very good practice to make sure that your title effectively communicates the topic of the page's content.
Use the description meta tag (<meta name="description" content="">) to gives any search engine a summary of what the page is about. It is very good practice to use unique descriptions for each page.
Use the keywords meta tag (<meta name="keywords" content="">) to give page related keywords.
Also, as far as images are concerned, I would recommend using proper use of alt and title attributes providing description of your image content. Image names can sometimes be composed of some identifiers which are meaningless for customers.
Please have a look at Matt Cutts Blog page: Gadgets, Google, and SEO where Matt describes in details importance of correct informations in alt and title attributes of an image tag.
I am creating a website with a rather lengthy medical questionnaire. The users/patients need to be able to hover or click on a medical term and see the definition.
What are ways to accomplish this in RoR? There are similar plugins for WordPress, but I haven't found any in Rails.
My idea is have a Term model, that has attributes "word" and a "definition". Then in my layouts, I have to somehow scan the page and output the definition.
There are multiple approaches. I use jquery-tooltip. I'm in the same boat, instead of medical forms in my case it's insurance forms.
I checked out a few different approaches. I really like the tooltip feature coming soon to jquery-ui 1.9. Until it's officially released, I'm using jquery-tooltip.
They both work the same, give an element a title:
<div id='q12', title='This is number 12'>
What is this?
</div>
Then
$('#q12').tooltip
If the only reason you ever give your elements a Title is to create a tooltip, then you can just use something like:
$("[title]").tooltip({ position: "center left", predelay:500 });
Then every element with a title defined will show your stylized tooltip when the element is hovered over.
Why not use Twitter's Bootstrap framework.
Modal
These can be customized with images and any other content that you need.
Tooltips
Mainly for small snippets of text.
Medical Term
Popovers
Can contain more information then tooltips, but not as versatile as a Modal.
You can find more information on using it in Rails 3.0/3.2 here.