Difference between revisions of "Accessibility Wishlist"

From Dreamwidth Notes
Jump to: navigation, search
(adding a sentence, fixing formatting)
(→‎General wishlist: s/Bugzilla/GHI/)
 
(19 intermediate revisions by 7 users not shown)
Line 1: Line 1:
 +
== General wishlist ==
 +
 +
At this point, pretty much everything in the wishlist should be a bug ticket -- put them here if there is still some question over whether or not they need to be in the [[Github Issues|bug tracking system]].
 +
 
* Have a question/option at signup which can funnel people into an area that asks about accessibility needs and shows them what's available for different accessibility needs.
 
* Have a question/option at signup which can funnel people into an area that asks about accessibility needs and shows them what's available for different accessibility needs.
  
−
* For extra shininess, if somebody uses the audio version of the captcha select this option automatically.
+
== Documentation wishlist ==
 +
 
 +
Put together documentation and make it publicly accessible and broadly disseminated from all the usual documentation places:
 +
 
 +
=== For Dreamwidth users ===
 +
 
 +
* [[Accessibility features in dreamwidth]]
 +
* [[Keeping your layout accessible when you customize it]]
 +
* [[How to write userpic descriptions]]
 +
* [[Links for end-users to ask for more help or make suggestions]]
 +
 
 +
=== For Dreamwidth developers, designers, and documentation producers ===
  
−
* Clear and accessible instructions on signup page on what to do if you can't complete the captcha for journal creation.
+
* Style creators: [[Creating an accessible style]]
 +
* Developers, style creators, designers: [[Principles of universal design]]
 +
* Developers: [[Resources for creating accessible HTML and AJAX]]
 +
* Site copy, FAQ, documentation, and support people: [[Avoiding language that assumes able-bodied users]]
 +
* Everyone: [[Accessibility Testing]]
  
−
* On all styles, have alt text for all images.
+
=== Useful resources to document ===
  
−
* Have a style which uses CSS to hide text alternatives for  all icon links, so "select link by name" works for tools which can't use alt text for that.
+
* Our in-house list of [[Accessible technology]]
−
:: Maybe I'm being thick headed, but I don't understand this. Using CSS to hide text alternatives for what specific purpose? Maybe including an example here would help, because this sounds like something that needs to be addressed by the developer of the tools "which can't use alt text for that". Is this a common problem? I'm not a blind user. I'm just hoping to understand this problem better. --[[User:Textish|Textish]] 01:21, 17 February 2009 (UTC)
+
* WebAIM (Web accessibility in mind) if a treasure trove of useful resources
−
::: (should we move this to the discussion page?) It's a keyboard control thing, not a blind accessibility thing. Actually, users with visual-impairment screen readers won't have an issue with this one, because those screen readers will correctly let you select alt text to go to image-only links. The problem is if you do your computer control entirely by the keyboard,and certain functionality is only accessible via image links, there needs to be a way to access the image links via the keyboard. Obviously, the correct way to do this is in the browser: Firefox does it right; Opera doesn't do it but has an open bug ticket; Internet Explorer doesn't do it and probably never will because Microsoft hates disabled people; I have no idea about Safari. But CSS-hidden textual links will allow keyboard access to those image-only controls on browsers which don't otherwise give access via alt text. Hiding them via CSS makes it invisible to anyone who doesn't want to see them. This isn't necessary on all functions, but for one style which gets as much accessibility functionality as possible crammed in there it would be awfully nice. --[[User:Jadelennox|Jadelennox]] 01:37, 17 February 2009 (UTC)
+
** [http://www.webaim.org/ Main site] and [http://www.webaim.org/intro/ introduction]
 +
** [http://www.webaim.org/discussion/ Mailing list] (low/medium volume, very good signal-to-noise ratio, beginner friendly)
 +
** [http://www.webaim.org/projects/screenreadersurvey/ Screen reader users survey] and [http://webaim.org/projects/screenreadersurvey2/ second screenreader survey]
 +
** [http://www.webaim.org/simulations/screenreader/ Screenreader simulation]: learn what it's like to use a screen reader
 +
* Accessibility validation tools. Note that no tool can do anything more than point out to you something you might look at. No "validated" site is guaranteed to be perfect. [http://www.w3.org/WAI/eval/selectingtools.html The w3c explains the limitations of validation tools and how to choose one].
 +
* [http://www.accessfirefox.org/ Access Firefox]: Mozilla's resource list
  
−
[[Category: Wishlists]] [[Category:Accessibility]]
+
[[Category: Wishlists]] [[Category:Accessibility]] [[Category:Documentation]]

Latest revision as of 13:14, 1 August 2014

General wishlist

At this point, pretty much everything in the wishlist should be a bug ticket -- put them here if there is still some question over whether or not they need to be in the bug tracking system.

  • Have a question/option at signup which can funnel people into an area that asks about accessibility needs and shows them what's available for different accessibility needs.

Documentation wishlist

Put together documentation and make it publicly accessible and broadly disseminated from all the usual documentation places:

For Dreamwidth users

For Dreamwidth developers, designers, and documentation producers

Useful resources to document

Retrieved from "http://wiki.dreamwidth.net/wiki/index.php?title=Accessibility_Wishlist&oldid=12038"