Difference between revisions of "Talk:Accessibility pledge"

From FSCONS wiki
Jump to navigation Jump to search
Line 53: Line 53:
 
==  Make slides available before the presentation ==
 
==  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” --[[User:Grégoire|Grégoire]] 08:58, 16 April 2012 (UTC)
+
: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” --[[User:Grégoire|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). [[User:Rikard|Rikard]] 11:30, 23 April 2012 (CEST)

Revision as of 10:30, 23 April 2012

What?

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…

TODO:

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.

Visual aspects

Slides generally

Color blindness

TODO: Template:Trim (User:Grégoire)


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)

Tiresias fonts are readable and Free --Rikard

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)


TODO: Template:Trim (User:Grégoire)

TODO: Template:Trim (User:Grégoire)

TODO: Template:Trim (User:Grégoire)


Use sufficient color contrast

Examples needed. Here's one set of font guidelines.

TODO: Template:Trim (User:Grégoire)


Todos

TODO: Template:Trim (User:Grégoire) Property "Has description" (as page type) with input value "Develop the audio/video section: divide into

  • 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.

TODO: Template:Trim (User:Grégoire)


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)