I wonder if anyone knows if the aria role=heading can be used for non-text elements (such as images) as well?
For example:
<img alt="..." role="heading" aria-level="1">
Thanks in advance.
Why not just use...
<h1><img alt="..."></h1>
...instead? This would seem to have the same functionality, but avoids the issue of whether ARIA is even supported.
This would also be search-engine (SEO) friendly, in that a web crawler will know that the contents of the is being used as a heading and will treat it accordingly, while it is very unlikely to look at the aria attributes.
Related
I am aware than in many cases an HTML element does more than simple affect the page semantically, and the additional functionality make it a no-brainer choice. For example, although there is a textbox ARIA role, it is nearly always preferable to just use an <input> or <textarea> element whenever possible.
However, for "semantic" HTML elements, I can't find any information indicating that they do anything more than supply a default ARIA role for the purpose of accessibility and provide some minor code readability enhancements. For example, the only purpose of the <main> element (as far as I can tell) seems to be a "shortcut" to avoid typing out a few extra characters <div role="main">, also resulting in a slight readability improvement.
So, is that tiny readability improvement really the only reason to use <main> over <div role="main">, or are there other reasons I might be missing? Is there any conceivable reason that I would ever want to prefer the latter?
Semantically structuring your page with semantic HTML makes the contents machine-readable for the browser, browser extensions, search engines and other tools without extending their code to cover ARIA as well.
This is especially important for accessibility, as assistive technology are such tools, which might attach additional functionality to certain roles.
The browser’s read mode, for example, can easily extract contents from a <main>. Also handling role attributes makes coding it more difficult.
Also writing user stylesheets to improve accessibility is way easier if you don’t need to cover ARIA attributes.
W3C has written a complete doc about using aria : Using ARIA by W3C
The first rule of ARIA explains that you prioritize the native HTML element or attribute with the semantics and behavior already built in.
In your example, the element is a native HTML element with an implicit main role. You can give a look to the complete list of implicit roles of HTML.
I'm tasked with evaluating some legacy web pages (classic asp) for accessibility. You can assume the HTML is not perfectly formed and that it's loaded with inline javascript and that we make use of javascript libraries that vomit HTML to create dynamic features. It's a circus in there.
While I recognize that the obvious answer is to re-write the page(s), that's not an option in our given time tables. So I'm trying to find the best way to make the pages work with a screen reader. Here's what I think I know.
We can use JAWS scripting to instruct the browser how to read the page.
We can use ARIA attributes to give the pages better organization and structure.
Specifically, I'm trying to figure out:
Question 1) If a JAWS script is present, will it be used exclusively by the browser/screen reader and ignore any improvements I make in the underling HTML structure?
Question 2) Could some well-place ARIA attributes give the page enough structure so that the default screen reader properties will work in an acceptable manner (without a JAWS script).
Question 3) I suspect the tough answer is that I would need to do both, which I'm trying to avoid because we barely have the capacity to do just one. But we don't want to lose a customer, of course. :-(
Many thanks for any input.
Instead of explaining only to JAWS how to access your pages, use JavaScript to explain it to any Assistive Technology (AT) for the web. I expect the same effort, while it will profit way more users.
In a JAWS script you would need to describe ways to access DOM nodes that are not accessible. That would include
speaking out information that you have to find elsewhere on the page
adding keyboard navigation where it's missing
Both can be done in JavaScript, probably even easier (you'll need to address DOM elements).
What you will need to avoid is restructuring the DOM and changes to classes, since those are most likely used by the scripts that generate them.
But I'd expect that adding attributes and keyboard handlers will do no harm to the existing scripts. Beware of already existing handlers for focus or keyboard events, though.
I would recommend making a list of attributes and handlers you suspect to conflict with the existing scripts, and searching the scripts for these, like onkeypress or onfocus event handlers.
The absolute best way to make your application/site accessible is to use semantic HTML. It doesn't matter if that HTML is generated by asp or jsp or whatever.
If you have a table, use a <table>.
If you have a heading, use an <h2>.
If you have a list, use a <ul>.
Use <section>, <article>, <nav>, <aside>, <header>, <footer>, etc
That's how you create structure on your page that a screen reader user will appreciate.
If you can't use native HTML, then fall back to ARIA, but treat it like salt. A little bit greatly enhances the flavor but too much spoils the meal.
If you can't use a native <h2>, then make sure you use the appropriate role and attributes.
<div role="heading" aria-level="2">this is my custom h2</div>
If you can't use a native <header>, then make sure you use the appropriate role and attributes.
<div role="banner">my header stuff goes in here</div>
I would recommend totally forgetting about JAWS scripts. It doesn't matter if that's what the customer thinks they should focus us. It's not about that customer. It's about that customer's customers. The end users. They should be able to use whatever screen reader they are used to using and most comfortable with. That's the whole purpose of accessibility - making the site usable and accessible by as many people as possible using whatever assistive technology they are used to using.
Following the Web Content Accessibility Guidelines (WCAG) will lead you to that result.
my title isn't brilliant, but I don't know exactly how to put it, I lack some knowledge. If you have a better title, please let me know :)
But the question is simple. Let me tell you the story. I blog with Ghost, and as most of us, I put some images in my blog.
I don't use the native way to insert images in my blog, aka:
Doing it this way is too restrictive, it doesn't allow you to add a caption or to change the image width. Instead, I write the HTML directly, and it looks like that:
<figure>
<img src="https://ghost.org/assets/logos.png" alt="Ghost Logos" width="80%"/>
<figcaption>Here come the logos</figcaption>
</figure>
And it works great! My only concern is that I have to copy/paste this all the time, which a little bit tedious.
So I was wondering if there is any way to, say, define a kind of function or macro or whatever, so that I just have to call it with some arguments (image source, width, caption), and it's automatically replaced by the HTML.
I know there are plenty of technologies under the hood of Ghost (Markdown, Handlebars, and probably much more), and that it can do a lot of magic. But I don't know ho to invoke it...
So if you're this kind of wizard and know a way to achieve that, please let me know :)
Before apps come along I don't really see this being possible within Ghost.
Until then I would suggest using some extension for the browser, either a Macro extension or something like Auto Text Expander which allows you to define your own shortcuts. You could for example use the following as an expansion for your figure-element:
Input: !!
Output:
<figure>
<img src="<!--?atec?-->" alt="">
<figcaption>Caption</figcaption>
</figure>
I am working on HTML5 and i came across various HTML5 semantic tags like <article> <section> <aside> <nav> <header> <footer> <audio> <video> <source> <track> <embed> <canvas> etc.
I would like to what exactly is the advantage of using these semantic tags. is it for fast loading or any other feature?
Please share your thoughts.
It's to accurately describe the content of the tag.
For example this means when Google (or any search bot) crawls a page, it can more accurately dissect it and assign relevance scores to the various bits of content.
Wikipedia has a nice simple definition:
Semantic HTML is the use of HTML markup to reinforce the semantics, or meaning, of the information in webpages rather than merely to define its presentation or look. Semantic HTML is processed by regular web browsers as well as by many other user agents. CSS is used to suggest its presentation to human users.
So whether a browser takes special action upon tags like audio and video is purely up to the developer of the browser rendering engine, but they are there to be used.
Advantages of semantic tags
It's easier for computers to understand what content is in your document and how it is structured. For example, having article tags would make it easier for a tool like Safari Reader or Readability to find the content of a blog post.
Screen readers will also have more information about what is on the page. This is incredibly useful for vision impaired users, especially since they can more easily jump to navigation controls and article contents while skipping less important content.
It's easier for developers to logically sort out parts of HTML documents, and easier to semantically add CSS styles around your HTML.
We are contracting an external consultant out to generate XHTML (Transitional) and CSS for most of the major pages of a new project we are currently working on.
I've been asked to put together a list of guidelines for them so that we can be sure that a certain level of quality can be expected. As a bit of technical background, we will be incorperating the raw HTML they provide into an ASP.NET web forms application (utilising the usual master pages / external stylesheets / jquery). Javascript should not be a consideration, but formatting and organisation of CSS should be.
I've made a start but quickly realised that this is probably not a unique situation and that a tried and tested list might be out there somewhere that I can at least use as a template! Has anyone got any experience of this?
From a technical standpoint, pages must pass validation is probably the first test I'd have.
I would expect the site to be able to be used by someone with JavaScript disabled, and someone using a screen reader (this is quite a good one as it should also highlight issues with inappropriately used tables and other things such as missing image alt tags, inconsistent use of header tags etc.).
One good test I always make for myself is opening the page and ctrl+scroll.
The zooming gives you an immediate idea about how flexible and liquid your design is.
In IE this tends to fail no matter what, but there you could also try to make the font bigger and see what happens (pay attention to buttons stretching vertically for example)
Give them a list of browsers (browser version and OS) you expect them to support.
Should the accessibilty guidelines be adhered? You could agree on supporing some of the points in the Checklist for Web Content Accessibility Guidelines. The list is actually quite usefull, since it will not only insure that your site works for people with disabilities but also for browsers without JavaScript, CSS, Images. The list also contains some general good practices for building sensible web sites.
Since you're using ASP.NET make sure that they only include one <form> per web page. Or at least, be prepared to make some workarounds, if you allow them to use more.
If you're planning on using AJAX show them ASP.NET AJAX Control Toolkit so that they don't spent time on things that have already been built.
I would insist on that they use some proven frameworks like YUI css reset and jQuery.
One thing that makes passing an HTML / CSS template between multiple front-end developers is proper structuring and indenting of the markup. The same way books are broken down into volumes, chapters, paragraphs, sentences, words, spaces, and periods, there is a hierarchical structure that makes HTML and CSS easy to read (and on the other hand a way of coding that makes things a total mess)
As a rule of thumb:
<body>
<div id="first">
<p>
Some text goes in here...
<p>
<ul>
<li>A list item</li>
<li>A list item</li>
<li>A list item</li>
<li>
<ul>
<li>
A link
</li>
</ul>
</li>
</ul>
</div> <!-- #first ends -->
</body>
This kind of adherence to structure can really cut down on time by making scanning code super easy for whoever is working on it– regardless of whether they wrote it or not.
Apart from validation the following points should be keep in mind
- Accessibility (Who are the audience)
- CSS based design (Where semantics are well designed)
- Be consistent with your naming convention (css and id naming. This will be beneficial in the long run when any change needs to be made, when a new css has to be applied etc).
Check out the following best practices from yahoo developer library...
http://developer.yahoo.com/performance/rules.html
Also since you are using ASP.net be careful when naming usercontrols as the client side ID that is generated could be quite long and unexpected(asp.net generates the id at runtime);
Some good info could be found at
http://woork.blogspot.com/2008/11/useful-guidelines-to-improve-css-coding.html
Indeed, make sure that the page passes validation.
Also pay attention to semantics, the page should be in a logical order when CSS is disabled (which is the case for some browsers and screen readers). Make sure that headings are actually <h#> tags and that all images have appropriate alt tags. Also make sure tables are only used to display information and are not used for formatting. The menu should be constructed as a list not as divs (semantics).