-
Notifications
You must be signed in to change notification settings - Fork 15
Requirements Analysis for 2021 Revision
Existing resource:
- Selecting Web Accessibility Evaluation Tools, which is associated with Web Accessibility Evaluation Tools List
- Revised Web Accessibility Evaluation Tools List draft
- Help people pick evaluation tools for their specific situation.
- Help overcome the overwhelming-ness of the Tools List.
- Explain the detailed info categories/filters in the Tools List.
- Warn what tools can't do (e.g., some things need manual, most need knowledgeable human).
- Anyone wanting to pick evaluation tool(s): web designers, developers, QA testers, project managers.
old version before 2017 revision
Goals for 2017 revision:
- Reduce approximately 50% of the page's word count
- Information should be clear nearly at a glance
- Create a document with reduced information, then link off for more "in-depth" information if needed. This would allow for basic information to be available easily without having to face a "wall of text" as well as providing more information for people that need it *Consider creating a more in-depth page of usages of evaluation tools if useful to provide further information.
This document is not about how or when to use evaluation tools. It is about what to consider when selecting a tool. The entire section of "Usages of evaluation tools" could be reduced to one paragraph. [2021 comment from ?DB?: Looks like some of this info is useful for understanding the different types of tools and for selecting tools. Consider if you want to integrate that part of the information in the Features section.]
The overall goal of the proposed rewrite was to make the content more human relatable. Studies in content strategy have shown that Millennial and Z-generation readers will invest more in a story than informational reading. Generation X and older users also benefit from this approach. By gearing the writing more towards a humanized tone and a storytelling approach we are more likely to engage users and therefore have them more engaged with the educational resources provided.
-
Upper Section: the proposed changes to the top center around making the content already provided more relatable. By using a slightly more conversational tone and placing the emphasis on the reader we may also be able to remove some of the intimidation that newcomers or those prone to imposters syndrome (~50%+ of technology professionals) may face when looking to learn more about this topic. As much as this is about the tools, the content itself should be on the people who are using the tools.
-
Lower Section: In the spirit of keeping focused on those that are using the tools, this next area breaks the tools down by use case. For generalists who may be overwhelmed, this helps to make this expansive suite of tools more “bite sized.” Meanwhile, specialists can learn more about how it applies to them. For example, many strategists still do not realize the inclusion created when including disabilities as part of the demographic and psychographic data that makes up a persona. Overall, by targeting the WAI’s personas more directly we are doing more to make them feel seen and addressing questions they may have.
The primary goal of all content strategy is to make the end user the hero of their own story: though the practice of this we are empowered to inspire as we educate to create more influential material.
Revision idea (Google doc) (will be put into GitHub)
30 April 2021 minutes= on keeping it more succinct.