This is a draft of a new policy for fscons. The idea is that speakers can, if they want, pledge to make there talk more accessible by following those guidelines. The talks will then be marked as accessible in the program. Most of this comes from this page : http://www.w3.org/WAI/training/accessible so before publishing anything, we should probably ask for authorization…
Make the short text explaining what the accessibility pledge is (for the CFP email), and a longer text for the landing page, where we explain that those who pledge also will have their sessions marked as "accessibility pledged" (or something) in the schedule.
- Page on color blindness [
- Can you see what I see?
- Colors for the color blind
- Color blind universal design
Use an easy-to-read font face
Needs examples, preferably including free readable fonts for print and digital (what is a slide display? is it still "digital"?)
- I think the main difference between print and screen, as far as types are concerned, is resolution: printed papers has a much better resolution than most screen (but e-papers and retina display might change that…) So a projector is definitively digital (they usually have crappy resolution) --Grégoire 08:28, 16 April 2012 (UTC)
- Makes perfect sense! //Rikard 12:16, 16 April 2012 (UTC)
- After a quick comparison, Open Sans has a lot more coverage. In addition, it as semi-bold and extra-bold styles (in addition to regular bold style) which is nice :-) --Grégoire 12:47, 16 April 2012 (UTC)
Use sufficient color contrast
Examples needed. Here's one set of font guidelines.
- Subtitles (for videos)
- audio description (for videos) and
- audio transcription (for audio)" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
Make slides available before the presentation
- I'm not sure we should include that. This impose a constraint on the presenter work-flow (some don't prepare in advance I believe) and some may not want to reveal too much of the content of their presentation before hand. But if we do include it, we should define what “in god time” means and it shouldn't say “if possible” --Grégoire 08:58, 16 April 2012 (UTC)
- We should include it as a "Good practice" rather than a requirement. During the accessibility conference I attended recently, we discussed policies a lot, and many came to the conclusion that "It's better that some efforts are made, than none (which can be the case when a package with a lot of requirements are presented. Some steer away and do nothing because the requirements seem "too much". I suggest we have two levels only: "You should" and "We recommend". Looser requirements like this, (I agree that while it is important, it is hard for some presenters) should be under "We recommend" (a section that could go to the end of the Pledge). Rikard 11:30, 23 April 2012 (CEST)