Important note: This Wiki page is edited by participants of the EOWG. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information.


Easy DD

From Education & Outreach
Revision as of 12:23, 24 May 2013 by Aleisers (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Nav: EOWG wiki main page

Easy Design & Development Analysis

This is the analysis page for a potential new deliverable(s) introducing a few easy things designers and developers can do to get started making their website accessible, similar to Easy Checks - A First Review of Web Accessibility.


Related material

WAI:

Others:

Issues

Major open issues:

  • Focus only on code level? Or also non-code design? Or also content authoring? All in one document? Or separate documents?
    • See the #Potential Topics section below for an idea of which topics apply to which tasks (coding, designing, content authoring).
    • [I don't think the line between code level and non-code design is that bright and clear anymore. They are pretty closely intertwined. While there may be some benefit to separating certain aspects of the development process that are specific to visual design, that part seems pretty small for its own stand-alone document in my opinion. {Sharron}
    • I wonder if this would be better just Easy Development and leave Design for another document to do another time? In other words focus on code in this document. So the primary audiences would be front end developers and back end developers, while designers would be a secondary audience. {Anna Belle}
  • What is the relationship of this work to the tutorials currently in development?
  • In titling this work, do we really want to call it "Easy?" Is it as easy to develop for accessibility as it is to check for accessibility?
    • I want to call it easy if in fact we come up with something that is easy. And I suspect we can. I want to get developers on board. If the W3C writes something and says it's easy, then I think a lot of developers would jump on it. It's not that they don't want to do this work. They get this deer-in-the-headlights look when I bring up accessibility, which to me says overwhelmed and don't know where to start. For the most part they don't want to read about it. They want to do it. So give them something easy to code. {Anna Belle}
  • ...

Goals

Goals/Objectives/Purpose:

  • Make it easy to get started with accessibility
  • Provide clear guidance from a reliable source
  • ...

Audience

Primary audiences:

  • Designers
  • Developers
  • Project Managers
  • ...

Secondary audiences:

  • Administrators
  • QA
  • Content Providers
  • ...

Feedback:

  • IMO primary audiences would include (1) Front end developers; (2) Back end developers; (3) Teachers; (4) Project Managers. Secondary audiences would be (1) Designers; (2) Others listed above. But that's because I want to separate design out of this document. {Anna Belle}

Use Cases

...

Approach

  • Briefly mention first steps like understanding the basics of how people with disabilities use the web & accessibility principles, yet focus on the practical what to do
  • Cover just the easy stuff at an introductory level. point to other resources (e.g., tutorials, understanding WCAG) for more details, explanation, and advanced stuff. similar to Easy Checks
  • Include reference to WCAG and, where appropriate (for example if discussing features of various CMS,) mention other WAI Guidelines.
  • Focus on code and give specific example code snippets {Anna Belle}
  • Focus on specific techniques or tips (this seems to be the case) or should we recommend a philosophy or strategy ala "Progressive Enhancement"? I.e. Start with Web Standards & Semantic markup; follow with specific accessibility tips ala the tips in the WebAIM blog post above{Howard - 9 March}

Draft

Outline

...


Potential topics

  importance ease Coding Designing Authoring more info available notes
image alt high understand: easy.
code: easy.
author: easy-medium.
always rarely yes new tutorial  
page title medium-high understand: easy.
code: easy.
author: easy-medium.
always no yes not needed?  
headings & lists high understand: easy.
code: easy.
design: easy.
author: easy.
always little little maybe not needed  
contrast/luminosity medium understand: easy.
design: medium?
no always rarely (take care with text and figures) maybe not needed  
Scalable Text medium easy/moderate         {Howard - 9 March}
No inline formatting high moderate         {Howard - 9 March}
Semantic Markup high moderate         {Howard - 9 March}
Keyboard Accessible High easy         {Howard - 9 March}
Clear links High easy no no yes   {Andrew - 10 May}


{LiamM} ... graphs and charts is a thorny issue that keeps cropping up for my clients. And form elements. And buttons generally. And search boxes. And sectioning elements. And Aria. Especially, especially form elements.

Title ideas

Brainstorms - put whatever you think of, even if you don't like the idea - in case it might spur an idea of someone else...

  • Easy Start - First Steps for Making Website Accessible
    or Easy Start - First Steps for Making Web Pages Accessible
    (to parallel "Easy Checks - A First Review of Web Accessibility")
  • if focus on coders:
    • Easy Web Code - First Steps for Accessible Markup
      (to parallel "Easy Checks - A First Review of Web Accessibility")
    • Accessible Code in 5 Easy Steps
    • Accessible Markup Made Easy
    • Accessible websites in 'n' Easy Steps
    • {LiamM} Easy Devs. For devs that are easy.
    • Jedi Dev tricks. Or....
    • Guru Dev Skills
    • Web Developer Accessibility Ninja Skills
    • Easy Code - First Steps for Accessible Development
  • ...

Misc Notes