2. Build in accessibility from the start (draft)

[mgifford]

This is often referred to as "accessibility by default" - most tech teams aren't starting from scratch.

Addressing accessibility early & often is key. It needs to be thought through the whole process.

The tie into open source thought is that there are existing open source libraries that are used. All libraries have accessibility problems in them. Government should be looking at the accessibility of all software projects to begin the process of selecting which stacks to develop on.

Whatever software is chosen, it is critical that government find ways to contribute back. Even if it is just submitting a bug report or a patch. Government needs to get involved in fixing the problem at the root.

Drupal is used heavily in government around the world. Contributions from all of them on web accessibility to Drupal 8 Core is still less than one blind Italian student. Government techies & vendors are not encouraged to actively contribute back, but they need to be.

[pjackson28]

The "Build in accessibility from the start" comes directly from the Digital Standards, but it is an interesting point about not always starting from scratch. The title does include "from" which implies throughout the whole process but that may not be clear for all. I'll pass along that feedback (fyi @tdandrea23)

There is also the following guidelines (also sub-bullets of the Digital Standards) which may help to address your concerns:

• 2.3 Co-create with people who have distinct needs, being inclusive from the very beginning
• 1.2 Empathize with the people using the service and have them engaged at all stages, from planning to ongoing improvements

As for your suggestions for open source, it would be good to have guidance covering contributing back to open source in general, particularly if you are using the software. Do you know of any material that would be a good source of checklist items and guides for contributing back?

@smellems @gcharest Any suggestions for good material regarding contributing back to open source (e.g., requirements, guides)?

[mgifford]

I've asked around for some information on contributing back. I don't know of any good resources on this at this point. I'll try to check in and get back to you.

[gcharest]

We're actually going over that right now @smellems and myself. We're planning on adding our work directly to the playbook but also as a list of requiremnts for whatever topics need to be added to policy instruments. Le jeu. 21 juin 2018 à 13:25, Mike Gifford <notifications@github.com> a écrit :

…

I've asked around for some information on contributing back. I don't know of any good resources on this at this point. I'll try to check in and get back to you. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#214 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABnJ5a70Tfzishwl7mEMzPps9706YGF9ks5t-9cVgaJpZM4UvWnz> .

[gcharest]

Of considerable note, the France policy is very interesting and will be referenced:
https://disic.github.io/politique-de-contribution-open-source/en/

[mgifford]

Thanks for the link to France's policy. I've tried to create a rough draft of ideas here:
https://github.com/mgifford/open-source-contracting/blob/master/encouraging-contributions.md

There are lots of ways to contribute that can make a big difference, but not cost a lot.

[gcharest]

Thanks Mike! Will share our working document as well and we can combine them together. Le jeu. 21 juin 2018 15 h 07, Mike Gifford <notifications@github.com> a écrit :

…

Thanks for the link to France's policy. I've tried to create a rough draft of ideas here: https://github.com/mgifford/open-source-contracting/blob/master/encouraging-contributions.md There are lots of ways to contribute that can make a big difference, but not cost a lot. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#214 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABnJ5eapEgejwBXx8pQg6N4ykZZQclqgks5t--7hgaJpZM4UvWnz> .

[JuliannaR]

I agree with the France part looking interesting. I think we have to be careful when pooling resources from other countries. It's okay to build on what others have done, its another to have conflicting information or information and best practices that may not actually meet the requirement of the GC.

I submitted feedback around w3c's policies and planning, implementation guides and specifically about building principles that build on foundational parts like Initiate, Plan, Implement and Sustain.

The current layout is very difficult to follow. It would be pretty awesome if there could be meetings with some of the stakeholders who contributed significant feedback on this area. Many of us are SME's in this field and compiling and presenting this information in a useable and meaningful way is critical to help build the capacity.

[JuliannaR]

This is a key concept when putting together any set of guides, checklists and components.

Initiate
Develop understanding of accessibility and build organizational enthusiasm.
• Learn the basics
• Explore the current environment
• Set objectives
• Develop business case
• Raise awareness
• Gather support
Plan
Develop clear goals and an environment that supports accessibility.
• Create accessibility statement
• Assign responsibilities
• Determine budget and resources
• Review environment
• Review websites
• Establish monitoring framework
• Engage with stakeholders

Implement
Ensure personnel are trained, tools are available, and accessibility is included throughout.
• Build skills and expertise
• Integrate goals into projects
• Assign tasks and support delivery
• Evaluate early and regularly
• Prioritize issues
• Track and communicate progress

Sustain
Continue to review and report on content, processes, and resources.
• Monitor websites
• Engage with stakeholders
• Track standards and legislation
• Adapt to new technologies
• Incorporate user feedback

[JuliannaR]

Area's focused on specific job requirements or views would also help alleviate the burden of reading and comprehension for those whom only utilize part of these standards/polices/guides/aides.

Writing for Accessibility
• Provide informative, unique page titles
• Use headings to convey meaning and structure
• Make link text meaningful
• Write meaningful text alternatives for images
• Create transcripts and captions for multimedia
• Provide clear instructions
• Keep content clear and concise

Designing for Accessibility
• Provide sufficient contrast between foreground and background
• Don’t use color alone to convey information
• Ensure that interactive elements are easy to identify
• Provide clear and consistent navigation options
• Ensure that form elements include clearly associated labels
• Provide easily identifiable feedback
• Use headings and spacing to group related content
• Create designs for different viewport sizes
• Include image and media alternatives in your design
• Provide controls for content that starts automatically
For a list of the WCAG success criteria that apply to certain areas, see:
• interaction design: How to Meet WCAG 2 (Quick Reference) – filtered for “Interaction Design” Tags
• visual design: How to Meet WCAG 2 (Quick Reference) – filtered for “Visual Design” Tags
• content creation: How to Meet WCAG 2 (Quick Reference) – filtered for “Content Creation” Tags

Developing for Accessibility
• Associate a label with every form control
• Include alternative text for images
• Identify page language and language changes
• Use mark-up to convey meaning and structure
• Help users avoid and correct mistakes
• Reflect the reading order in the code order
• Write code that adapts to the user’s technology
• Provide meaning for non-standard interactive elements
• Ensure that all interactive elements are keyboard accessible
• Avoid CAPTCHA where possible

[gcharest]

@JuliannaR @mgifford
The repo I created is more geared towards rules that will most likely sit in a policy instrument. A lot of the elements you pointed up here should definitely fall under the Playbook.

For instance, I wouldn't add sections regarding use of mark-up in the other document but that would sit better here. I also think that Paul's team was trying to have a set of scenarios where we can build a tailored checklist.

Again, the mark-up use is relevant for webdev but would not apply to other situations such as releasing a library. Maybe @pjackson28 can elaborate further about that angle. Might be easier over a coffee than in a thread though.

Also, when I'm referencing France's policy, I'm saying that portions of our documents will be inspired by it, not that we'll blindly take their work. We're also heavily inspired by UK and the US as well but are working with Canadian lawyers to make sure that we move in the right direction from a legal standpoint as well. Also, none of these countries have two official languages which is the case for us. Lots of differences so we are building on their great work to get the best outcome possible for ourselves!

Who knows, maybe we'll inspire some others here after!

[gcharest]

@mgifford for the elemets you find to incite to contribute back, I'm sure the People Working Group would benefit from it. Thanks!

[JuliannaR]

@gcharest I completely agree.

I drafted two documents one, aimed at the playbook and the other a policy instrument aimed at hoping to update the web standards in terms of accessibility.

I've been working with a few people from around @pjackson28's team too.

We should never be blindly taking anyone's work for the most part. We need to do our own research. But leveraging what others have done can highlight key elements for us, which is what I was referencing. But yes, coffee might make it easier.

Engaging in the discussions are half of the battle.

[mgifford]

@gcharest Should I sign myself up to the People's Working Group? Some good people there.

[pjackson28]

@JuliannaR Thank you for the feedback! The goal is to avoid taking a one-size-fits-all approach and instead to provide personalized guidance for a variety of common tasks/scenarios. For each task/scenario, only the relevant guidance would be provided and it would be structured and organized according to that task/scenario (so the guidance is adapted to each task/scenario rather than readers having to figure out how to apply the guidance to their specific tasks/scenarios).

The way we are approaching this is essentially creating a knowledge base that houses the guidance which would then be used to generate the personalized guidance for each of the supported tasks/scenarios. The pages for each of the Digital Standards aren't really intended to be the primary way of using the Digital Playbook as their primary purpose is to be authoring files used as the source of content for the knowledge base (we have a script that extracts the content and mappings from those pages to create a JSON file that will then be used as the content source for generating user-friendly "views").

The authoring pages are more focused on creating mappings and groupings for the dataset rather than being easy to read. What is intended to be user-friendly and easy to read are the "views", which would be the means of providing the personalized guidance, and in the future the primary way of using the Playbook.

Now we are just getting started on developing "views", and it will require working with the community and potential users to design these "views" and to make sure they meet their needs (so user research and testing). We welcome suggestions for which tasks/scenarios should be focused on and how to approach views for them (and welcome any other help you can provide).

An early rough example, is the GC EARB view (draft). It is generated from the dataset, pulling together the checklist items from various standards that projects would need to meet to get endorsement from GC EARB (guides and other items will be displayed as well once they are mapped to the view). It is still quite rough but gives an idea of how we can mix and match, group and order content to produce whatever outputs are needed by the user.

Now for how to design these views, here is a possible way we could go about it, involving the community and potential users:

1. Identify the top tasks/scenarios that would benefit from personalized requirements and guidance
2. For each task/scenario, identify the discrete steps.
3. Map relevant requirements and guidance to each discrete step and also identify what content gaps exist (ideally would involve users).
4. Develop content to address the gaps for each discrete step.
5. Identify how to present the content to best meet user needs (e.g., come up with a simple and intuitive design that is suited to the task/scenario). Design should be tested with users (iteratively improving the design based on user feedback).
6. Implement the mappings (e.g., content to discrete steps) through tags (so have one or more tags for each discrete step, and then apply those tags to the relevant content)
7. Build the "view" using the tagged content (according to the planned design).
8. Test with users and iteratively improve/refine the "view".

I hope this helps to explain what we are trying to do. It hopefully will get a lot easier to explain and understand once we have more "views" built.

[gcharest]

@mgifford Please do join us. Anyone else interested in helping bust myths, raise awareness and the engagement of the community is welcome.