a11yproject / a11yproject.com Goto Github PK

IMHO it would make sense to have at least one source for every recommendation ("further reading").

Anyhow, great project!

Need to either find a workaround or abandon this solution :(

HTML Related

• W3C ARIA Unofficial: Recommended ARIA usage by HTML language feature

Blogs

• A11y Buzz

Further Reading

• Why mobile Web accessibility matters - best practices to make your mobile site accessible
• 10 Easy Things All Web Developers Should Do For Web Accessibility

Hi,

Interesting project, I just subscribed to the RSS feed and noticed a post about accesskeys. I noted two things:

1. The post isn't published, but it is still in the RSS feed. It leads to a 404 if you select the link.
2. I don't think accesskeys are in anyway recommended these days, so please check about this carefully before publishing. See:
   http://john.foliot.ca/more-reasons-why-we-dont-use-accesskeys/

Kind regards,

-Alastair

@mattmcmanus
@davatron5000

It's late for me but does anyone else see the navigation acting strangely on the live site compared to the local copy?

Hey friends,
Derek Featherstone from Simply Accessible reached out to me over concerns about the similarity in naming. I understand his concerns and he's a real great guy, well-respected in the field of accessibility. So I'm proposing (strongly) that we change the name in order to be good neighbors. I bought 2 domains:

• http://open-a11y.com - in order to cause further confusion with http://opena11y.com, a Linux Foundation initiative.
• http://a11yproject.com - I like this one because it highlights the open ended nature of the project. Here's what it'd look like.

This might be a good time too if we wanted to start a Github Organization rather than just a repo under my account. It as much yours as it is mine.

If you have strong oppositions, let me know. Otherwise, I'd like to get started as soon as possible.

Paging @Wilto, @grayghostvisuals, @mattmcmanus, @bryanstedman, @OliverJAsh to the chat room.

On the archives page (http://a11yproject.com/archives.html), there is a link to the "How To Add Keyboard Navigation with Access Keys" article which has been removed, thus it is throwing a 404.

(New to issues, I don't see how to add a label as bug.)

It states in the checklist that aria-hidden should be used to hide content from all users (incl. visual browsers). This is not entirely correct. The spec states that the means of hiding content with this attribute is up to the author, and it further says:

"Authors MAY, with caution, use aria-hidden to hide visibly rendered content from assistive technologies only if the act of hiding this content is intended to improve the experience for users of assistive technologies by removing redundant or extraneous content. Authors using aria-hidden to hide visible content from screen readers MUST ensure that identical or equivalent meaning and functionality is exposed to assistive technologies."

In other words, using aria-hidden to just hide content from screenreaders but not from visual browsers is allowed. to hide from all UAs and ATs it would be better to use the HTML attribute "hidden"

Posted in a gist for editing and commentary before committing.

Point two under Writing articles we state

Claim an article by starting a new issue with the article title and assign the issue to yourself. The final title can (or probably should) be different.

As it is now we can't assign issue to a person or set a label. Would it be possible to fix this or should we change the document?

As months/years go by having a date on the articles may give readers the idea that they aren't giving them up-to-date information.

Alternatively you could have a last updated date - but correct information might never go out of date so the problem remains.

Just a thought.

Yeah, I'm a grumpy old man that still likes rss. PS, I'd be happy to look into adding this.

I wrote up a little something on the alt text and it can be found here:
https://gist.github.com/4534815

Feel free to expand or change anything.

Started writing an article on Section 508 and how it specifically relates to web design.

https://gist.github.com/f2b8ad70543a95018d9f

Looking for feedback over there on the ?? questionable things (like I wouldn't even recommend these in modern web design) or I can't find a clever way to simplify what they're talking about.

I'm surprised this hasn't been written yet. Just google chrome outline and pretty much all the results at the top will be advocating the use of *:focus { outline: none; }. Pretty sad.

Simple, bite-sized snippets of content to teach A11Y in smaller pieces instead of big chunks. We can check them off (using githubs new todo list feature) as we get them finished.

📈 == A table or chart here would be useful.

Concepts

Basic introductions to various concepts. What is it? Why does it exist?

• ARIA introduction: roles 📈
• ARIA introduction: states 📈
• ARIA introduction: properties 📈
• Basic ARIA roles
• Basic ARIA states
• Basic ARIA properties
• Color blindness
• Color Contrast
• What is WAI? The Web Accessibility Initiative
• Section 508
• WCAG 2 (38 reqs)

Features

• Accessibility Checklist
• Resource Page

Quick Tips

Quick, tiny, easy improvements for maximum ROI

• Using alt text correctly
• Using title attributes correctly
• Never use maximum-scale=1.0
• Prefer button to div elements https://staging.w15y.com/shortcuts/prefer-button-to-div
• Avoid -webkit-text-adjust-size: none; http://codepen.io/davatron5000/full/14/7

Quick Tests

• Navigate using your keyboard
• Test contrast on your phone
• Larger Touch Targets
• Accessible Typography (considerations: larger font-size, etc)

HOWTOs

More in-depth, yet simple articles on HOW-TO use/create something.

• HOWTO: Use VoiceOver on iOS
• HOWTO: Use NVDA on Windows
• HOWTO: Use JAWS on Windows
• HOWTO: Use VoiceOver on Mac
• HOWTO: Make an accessible <nav> with dropdowns @jimbateson
• HOWTO: Hide content
• HOWTO: Write accessible FORMs
• HOWTO: Make accessible VIDEOs: <track> & HTML5 Video Controls
• ?? HOWTO: Make accessible CANVAS & SVG ?? (2 posts?) @CBID2
• HOWTO: Ajax with ARIA-LIVE
• HOWTO: Make accessible dialogs and modals
• HOWTO: Test text at 200%
• HOWTO: Em-based Media Queries
• HOWTO: Accessible Animations (i.e, they're frustrating)
• HOWTO: Use Access Keys

Myths

• MYTHBUSTED: Accessibility is “blind people”
• MYTHBUSTED: Screen readers don't use Javascript
• ?? MYTHBUSTED: Accessibility is just turning off CSS ?? @JSmurf

Assistive Technology (AT)

• NVDA: The OpenSource Screen Reader
• High Contrast Mode
• User Zoom
• Dyslexic Fonts

Videos

• Video: How a non-sighted person uses a screen reader
• Video: How a partially-sighted person uses High Contrast Mode
• Video: How a mobility-limited person uses a website

Misc.

• Firefox & Accessibility (aka, Don’t neglect FF).
• ?? Myths: A11Y and SEO (myth confirmed?) ??
• SPANS. pause. screen. readers. (aka, "Why Lettering.JS sucks")
• ?? Cheapest way to get audio/video transcribed ??
• ?? Making Bootstrap Accessible ??

Hey friends,
I got another Quick Test article and would love feedback before I roll it in.

https://gist.github.com/965cc1cf34f0955c57a1

Cool Story, Bro: I tried it on my own site and my site sucks and has problems 👊 👨 I knew I was riding the line but it's very apparent I have a problem.

There's CSS everywhere. I'm gonna clean it all up. Don't youse guyse worry.

The .masthead only has gradients on it and not a fallback background color for IE, so the white text is lost in IE9.

This idea came to me after I went into my iPhones accessibility options and started to try some of them out. The VoiceOver works really good and I think (as a quick tip) to let people know that accessibility is still important for mobile web pages.

You can read and leave feedback here : https://gist.github.com/4633248

Posted in a gist

Change the example

Would you like a quick tip about avoiding the use of autoplay on videos/sound clips?

This is obviously bad for SEO purposes. The two options I can think of are:

1. Truncate page.content in the default layout if the current page is a post page.
2. Use the TLDR from the YAML headers that is already being defined, albeit quite a short one.

I noticed there isn't any analytics on the site. @davatron5000, since this is your brain child I image you would want to set it up under your own account. If you uncomment the lines for GA in _config.yml it should automatically add to the site.

Looking through this I can probably add:

• HTML5 <header> tags
• role="navigation"
• role="main"
• role="banner"
• role="content-info"

Basic information about access keys to allow for keyboard navigation. Post coming shortly.

One thing that stopped me prevented me made me feel it was ok to ignore accessibility was my selective ignorance to the real world figures of visual and hearing impairment. Once I bit the bullet and decided to investigate this it completely engaged me in accessibility and I think this would be a real sell to other developers if they could appreciate the shear numbers of potential users involved when it comes to accessibility.

https://gist.github.com/4542624

I'll PR it when we feel it's done.

Edit: I wish there were notifications on the comments for gists .. Probably better to actually comment on things here on the actual issue. Will copy the comments over.

"develoer" should be "developer" in the first sentence

So glad to have learned about this project yesterday. I'm a 16-year web developer, currently working for an agency in Atlanta, GA. In my ENTIRE career, both freelance and working for agencies, I'd never dealt with accessibility. It's not that I didn't care, but it's that either a) none of my clients cared, and/or b) they could never afford the extra effort.

After joining my current agency, I started working on web apps for Wells Fargo bank. And they are fanatical about accessibility. They have to be, or they have to answer to the department of justice. Nothing we do for them can be called complete until it passes accessibility review.

So I was thrust into this whole arena to sink or swim, having almost zero knowledge of how to do it. Over the past 10 months, I've built a couple things for them, most notably this single-page "e-magazine" (https://www.financialadvisorinsights.com), which at first we didn't think could even be done accessibly.

I've learned a ton, and yet STILL feel like I don't know what I'm doing. For instance, I still have no idea how to use the JAWS screen reader to save my life. One saving grace has been that our main accessibility contact at the client is actually blind himself, and he's been a huge help in determining if this stuff even works.

So, in short, I don't know how helpful I can be, but I'd really like to contribute to this project. I'll be jotting down some article ideas soon, and maybe I can help with some of the existing ideas list. I could probably easily put something together like doing keyboard accessibility with jQuery, doing "skip to nav" functionality, etc.

Thanks again to everyone that's made this happen. It's odd that in 2013 this is still such an obstacle, but hopefully things will get easier :)

Think the advice needs to be more nuanced, in many cases aria-hidden=true is unnecessary and aria-hidden="false" is unnecessary as it does not signify visibility. refer to discussion: http://www.paciellogroup.com/blog/2012/05/html5-accessibility-chops-hidden-and-aria-hidden/

Thoughts on unpublishing http://a11yproject.com/posts/keyboard-navigation-with-access-keys/ based on feedback found via a Twitter post:

https://twitter.com/codepo8/status/291285217082216448

Overriding key commands is probably unrecommended (except by the UK government apparently).

Paging: @erunyon to the room.

@grayghostvisuals Let's add an accessibility checklist. I think it'd be handy in HTML. Features I think it should possibly have:

• Dedicated page /checklist.html
• Actual checkboxes? Maybe custom "fat" checkboxes (nothing like that in Bootstrap).
• localStorage() ?

The importance of understanding the user before the machine is as important, if not more important, than accessibility implementation itself. Developers need to understand the real world definitions of visual and hearing impairment so they can better understand how people with disabilities are defined and categorised.

The article will cover key facts, definitions, types, causes, prevention, social and economic impact, global response, who is at risk, organisations and resources.

The first step towards a solution is to understand the problem.

The logo.svg image won't display in browsers that don't have SVG support. This would be primarily for <IE9 and stock browsers on Android <3.0. I recommend a simply PNG fallback. I'd be happy to take that on for you. http://caniuse.com/#search=svg

"assitive techonology" should be "assistive technology".

Last list item should to end with a full stop.

http://a11yproject.com/posts/alt-text/

I hope that's helpful!

issue #5 reference

@Wilto
Other thoughts besides localStorage for persistent checklist states? What about IndexedDB? Or is that overkill?

The current state of ideas being tossed around like 🍶…

@davatron5000 mentioned

1. "multiple persistent checklists (Project 1, Project 2, Project 3, etc)."

Thanks so much for your interest in helping make the web more accessible. Welcome and I'm so glad you're here. This site is as much yours as it is mine.

So the pitch:
I've been making web sites for over a decade now but web accessibility (A11Y) still seems to be the area where it's most difficult to grasp best practices. Furthermore, when you search for information, it's buried in long posts. I want to make A11Y easier to digest so that designers and developers can make more easily these considerations and make the web a better place.

Awhile back I created a list of ~40 simple posts on A11Y that I would love to see written. It's by no means the end-all-be-all, but it should be straightforward on the type of posts I'm after: small, topical and friendly.

And because this is all on Github, information can always be the latest and have the input of the whole web. Here's a list of people who said they were interested or have mentioned it in the past:

@Wilto
@ianhamilton
@bryanstedman
@sturobson
@susanjrobertson
@mattmcmanus
@grayghostvisuals
@joshualong
@jasonrhodes

The site isn't ready for launch yet by any means, so keep it a bit of a secret right now. I'll start logging issues that I have with the site at the moment and assign some to myself and start clearing them out.

If you are jekyll and github savvy and you'd like to become an admin, just post an

Thanks again for helping,
Dave

The off-screen text technique to hide text visually and still have the text available to screen readers, while still occasionally useful, has been superseded by aria-label in most cases. Rather than encouraging more use of a hack it would be better to point people to more modern techniques.

Accessibility is missing an i in the title Web Accessibility Checklist.

I really like the idea, the project and the everything it stands for. I look forward to contributing but I have one question. Do you think it would serve the developer / community better if A11 Project has a Section 508 Boilerplate? Similar to HTML5Boilerplate? Just how each line of code is explained in the HTML5 Boilerplate so can lines of code be explained in section 508 Boilerplate.

The site http://www.w3.org/WAI/demos/bad/ show annotations and side-by-side comparisons which helped me convey the point to other developers unfamiliar with WCAG 2.0.

I just think having a Section 508 Boilerplate would be an awesome tool in anyone's toolkit. Help other developers retrofit their website. Lead the charge in best practices for accessibility. Include things such as "Skip to Content" skip links that only show on :focus, or hidden TOCs or other practices developers do when making a 508 accessible site.

Perhaps also incorporate practices from http://webaim.org/.

I'm going to write an article about role="application" and why we should only use it sparingly if at all. There were some warm fuzzy feelings #28 on this topic so it seems like a great bit of info to inform people about.

please have a read of https://dvcs.w3.org/hg/aria-unofficial/raw-file/tip/index.html#application

Hi All!
Great work so far. I've been at work all day itching to see what you all were up to. Anyway, I was thinking it might be useful to have a section with other resources like validators and even some downloads. Downloads might include a sample/starter template with WAI-ARIA Landmark Roles properly in place.

Also maybe a "Quick Wins" post would be helpful. Or perhaps a section that boils down the easy places to start...

Not so much innaccuracy as requiring some more information.

• "not necessary for understanding the content of the page (alt=”“).", I'd also note: "If, for example, the information in a graph is explained in text below it, there's no need to duplicate that in alt text"
• I'd add "images that are links should describe where they go. For example, a logo that is a link to your home page should have alt="homepage".
• I'd also add "Alt text describes the function of an image,and is rarely a detailed description of the image itself"
• I'd also add "Never begin alt text with "photo of.." or "picture of.."; assistive technologies already do this. Redundancy and repetition is almost as bad as not enough information.,

(Is the article on github for me to amend a send a pull request?)

Online Tools:

Contrast-A
http://www.dasplankton.de/ContrastA/

this is useful for developing and testing accessible colour combinations. It provides detailed information on contrast thresholds and WCAG guidelines.

Hey guys, awesome initiative!
I was just wondering if your checklist's advice to use <section role="main"> is still the most appropriate with the newly included main element.

Obviously those new HTML5 elements do not do much for a11y at the moment — none of the semantics have been implemented — but still the <main/> element might be more appropriate for the main ARIA role, no?