Accessibility and New Site Design
Accessibility is one of those things that is sometimes overlooked, or considered as an after thought when it comes to Web design.
At the moment, every page I publish goes through numerous tests. HTML5 and Microdata have added to the number of tests performed, as have social media sites.
Previously I would simply test if the HTML was standards compliant. While that is still the case, by utilising HTML5, Microdata, Twitter Cards, Facebook Open Graph, and Google Rich Snippets, I now run a page through multiple tests instead of just the one.
That is why I think HTML5 brings with it some accessibility improvements.
When I run a new URL through the Google Webmasters Structured Data Testing Tool, I can see if things like collections of images and links are detected correctly.
If, for example, an article snippet on the Home Page has one too many (or one too few) closing </div> tags, then it will mess up the number of items detected in the structured data testing tool. Likewise it will show an HTML validation error, even if I don't notice a problem with the page visually.
If there is a problem with the metadata of a page (which is not only used for the metadata, but also the <title> tag content, main <h1> content, and introductory paragraph(s) content, then it will show as a problem in the Twitter Card tester and the Facebook Open Graph Debugger.
Thus, even without deliberately testing for accessibility, by running a new page through the W3C validator, the Google Structured Data Testing Tool, the Twitter Card Validator, and the Facebook Open Graph URL Debugger, I have quadrupled the number of tests being performed that might catch something that is a major issue.
That is not to say that these tools are able to catch accessibility issues with the main content of a page, for that further testing is necessary.
Known Accessibility Issues
Some accessbility issues are obvious even without using a screen reader if you know what you should be looking for.
Breadcrumbs
Take the breadcrumbs on every page. Before using iOS VoiceOver I thought I was doing things correctly by using the ARIA roles Menu and MenuItem. I was wrong. On my iPad the breadcrumbs were read as list items, but each item was listed as "list item" and nothing more descriptive.
Although I have somewhat improved the main breadcrumbs of a page, I still need to do some research and consider how best to do things. VoiceOver, for example, reads the slashes between the breadcrumbs. Although considered bad practice, isn't it descriptive of the location of a page within the site? As I said, more research is needed.
Social Sharing
The twitter share icon and icon count are another accessibility issue that has been introduced. Most of the time it is read as "Tweet, Link, Zero, Link" which is rather undescriptive.
Alert Boxes
The alert boxes, such as the font loading alert box, is another accessibility issue. Upon closing it, VoiceOver doesn't know where to go so highlights the Safari back button, rather than the page heading.
Main Heading with Sub-Heading
By using VoiceOver, I stumbled upon another accessibility issue that I was already aware of: sub-headings.
Sub-headings (e.g. something more descriptive for an article that is part of a series) are currently spans within <h1> with a class of subheading and also within <small> tags.
In iOS Safari, when going through links by pressing the L key when VoiceOver is enabled, the subheadings are read as if they are a completely different heading. That is not how it should be.
I have not yet implemented the fix, but my proposed change that still requires coding and testing is to move the subheading to an <h2> and surround the whole heading in a <hgroup>, with some CSS modifications so the styling remains the same (possibly just adding a subheading class to the h2 will suffice).
Code and Sample Blocks
Code blocks and sample blocks are another accessibility issue, and I don't know how best to deal with them.
Resolved Accessibility Issues
HTTPS Link
The padlock icon is an annoying issue that I don't yet know how to fix.
The padlock icon now uses an ARIA label. If not on the secure version of the site, the label indicates a secure version is also available. If on the secure version of the site, the label indicates the page is secure.