Feedback: Implementation Plan for Web Accessibility

Please provide your comments inline below.

Comment template:

summary — comment {name, date}

Feedback October 2014

open comments

summary - comment {name @@ Oct 2014}
link to Improving
- needs to point to "Improving the Accessibility of Your Website" saying what they'll get there. {Shawn 3 Oct 2014} Here's an ideas that adds to the intro idea in my 14 Oct e-mail {updated 16 Oct to change CIO}:

A successful plan for web accessibility addresses many areas of your organization and projects: training, quality assurance, recruiting, purchasing, marketing, content development, visual design, and more.

This document provides IT managers, project managers, small business owners, accessibility consultants, and others with guidance on what to consider in developing an effective web accessibility plan for your specific organization or project. When you want more tactical guidance on fixing accessibility barriers in existing websites, see Improving the Accessibility of Your Website.

- +1 to Shawn's intro suggestion, it is focused, clear, and concise {Sharron 15 Oct 2014}

Strategic Planning references throughout - Now that we have changed the title, we might consider weaving more references to that process into the narrative of some of the sections. {Sharron 15 Oct 2014}
- Done {Kevin, 16 Oct 2014} For example, in Determine Your Goal and Gather Support, I suggest modification of the first sentence to "Strategic planning, whether for a single project or entire organizational processes, requires broad backing and support." {SR}
- Done {Kevin, 16 Oct 2014}Develop and Implement Organizational Policy, suggested rewrite of intro narrative: Omit first sentence. Modify second sentence as follows: "Establishing an organizational policy for web accessibility is a critical milestone in ensuring that web accessibility is understood as a strategic component of the organizational structure. Explicit policy statements document the commitment to accessibility and help to set expectations both internally and externally." Within the "Review related policies...." bullet, add the following "Most organizations have policies governing both broad aspects of doing business as well as specific areas such as procurement and marketing. An effective accessibility strategy will take into consideration existing policy and develop accessibility statements that can be integrated into what is already in place. For example...." {SR}
- Done {Kevin, 16 Oct 2014} Review Available Tools and Resources Omit this sentence: "If you are looking to improve organization-wide accessibility, reviewing and improving resources that all projects use is a efficient way to bring about extensive change." Replace with "Many organizations standardize I.T. operations using common development tools, design patterns, and code libraries. Review these kinds of resources and implement a focused effort to improve their accessibility in order to efficiently achieve extensive change." {SR}

addressed comments

important to address before publication even as a draft

Removed for draft release, worth discussing at a later date {Kevin, 14 Oct 2014} Provide a developer checklist of applicable criteria and relevant techniques." This is very risky. I think we do not want to recommend this without clear caveats -- so probably not in this iteration of the doc. {Shawn 3 Oct 2014}

Done {Kevin, 14 Oct 2014} Run iterative checks to allow teams to explore solutions for issues for which there is no clear solution." - "there is no solution" jumped out at me. I suggest a different spin, such as "Run iterative checks to allow teams to explore different solutions for complicated issues." {Shawn 14 Oct 2014}

Done {Kevin, 14 Oct 2014} "Acceptable solutions that address all constraints will emerge" I don't think we can say that. I suggest deleting this sentence or changing it. {Shawn 14 Oct 2014}

Done {Kevin, 14 Oct 2014} "Consider reviewing resources such as personas, user stories, and storyboards. Incorporating the needs of users with disabilities into these assets can help designers and developers understand barriers faced." How about something like "... can help designers and developers understand how people will interact with your website." or "... can help designers and developers understand how to avoid accessibility barriers in your website." {Shawn 14 Oct 2014}

Made this more about 'key team members' and 'relevant project teams' {Kevin, 14 Oct 2014} "Run whole team accessibility solution reviews. Have representatives from all project teams..." I think some people would disagree with this. In a very large organization where distinct tasks are in different departments, I think some would say it is a waste of time, for example, for copywriters to be in a meeting discussing coding issues. {Shawn 14 Oct 2014}

Done {Kevin, 14 Oct 2014} "In smaller teams it is likely that one individual will hold sole responsibility for accessibility." While that may be true, we don't want it to be and so I don't think we should say it. Ideally everyone on the team has some responsibility for accessibility. How about change 'hold sole' to 'have primary': "In smaller teams it is likely that one individual will have primary responsibility for accessibility." {Shawn 14 Oct 2014}

can be for later

Changed to 'from early planning to final deployment' {Kevin, 14 Oct 2014} whole process - "Regardless of your development methodology, integrate accessibility throughout the project from design to final user acceptance testing." Actually, it should be incorporated before design! :-) Also, do most organizations do user acceptance testing? If many not, then we shouldn't use that specific. {Shawn 14 Oct 2014}

Removed as the checklist action was removed. Can be revisited later {Kevin, 14 Oct 2014} not link just to Techniques - "Related resources... Techniques" I'm not comfortable about pointing to Techniques by itself. Seems should at least include a pointer to the context: http://www.w3.org/TR/UNDERSTANDING-WCAG20/understanding-techniques.html

tone - Examples where I'm not sure about tone: {Shawn 14 Oct 2014}
- Done {Kevin, 14 Oct 2014} "Whether your accessibility goals are confined to a single project or are aimed a widespread organizational change, you will need to ensure that you have suitable backing and support." I'm not sure if "you will need to" is a tone we want to use?
- Done {Kevin, 14 Oct 2014} "If you are looking to improve organization-wide accessibility, reviewing and improving resources that all projects use is a great way to bring about extensive change." Not sure about "great" here.
- Done {Kevin, 14 Oct 2014} "Encourage team members to attend testing sessions as this provides tremendous insight into barriers and helps team members identify with the problems caused." I agree it's tremendous, but not sure about that tone. :-)

clarity - Examples of editing needed for clarity:
- Done {Kevin, 14 Oct 2014} "Sharing helps avoid repeating problems and in spreading best practice solutions."
- Done {Kevin, 14 Oct 2014} "This is beneficial if your organization has many websites to provide an overview of improvements and areas still in need of attention."
- Removed {Kevin, 14 Oct 2014} "Your project plan is unlikely to include an open-ended monitoring phase, which makes it more important that consideration is given to how this ongoing activity will be managed."

grammar - Examples of editing needed for grammar:
- Done {Kevin, 14 Oct 2014} "This helps to focus your team, clarifies what activities need to be planned, how support can be best secured, and what deliverables are required."
- Done {Kevin, 14 Oct 2014} "If the website being created or a part of it, such as the visual design, is outsourced to an external company, make them aware of your accessibility policy."

active voice - Examples of editing for active voice:
- Done {Kevin, 14 Oct 2014} "… and allows for the identification of additional training needs." -> "helps identify additional training needs."

tersify - Examples of editing to tersify:
- Done {Kevin, 14 Oct 2014} "When planning the creation of a new website" -> "When planning a new website"

Questions to consider

For this week, please only focus on Introduction, Determine Your Goal and Gather Support, Integrate into Project Life Cycle, and Ensure Ongoing Monitoring and Maintenance.

How well is accessibility being explained and communicated as an on-going effort, rather than a start-to-end process?

Seriously great work — It's like a completely different document! In my opinion, the changes are transformative across-the-board. Readability and understandability are vastly improved. Again, VERY nice work. {Paul, September 4, 2014}
summary — comment {name, date}

How easy is it to follow for people who are new to accessibility, yet how flexible is it to address different situations?

summary — comment {name, date}

How succinct is the information provided, how clear is it, and how well does it guide people to taking real actions?

summary — comment {name, date}

Feedback on other aspects

I skimmed through the sections titles and some are not so clear to me: Example: "Start early and factor for iterative checks.", "Plan for a reasonable gap between completion and go live to address any final barriers." {Sylvie Duchateau, 5 Sep}
- I wonder if the context is being lost by this point. These titles are contained within the broader title of 'Integrate into Project Life Cycle'. The titles are as succinct as possible, I wonder if this is a case of overly succinct? Or whether the language used is not suitable for non-native English speakers? {Kevin, 8 Sep}

Update footer. add WAI-ACT funder as appropriate (check with Shadi) {Shawn 11 Sep}

[Done, Kevin, 5 Sep]: Broken link — In expansion of "Provide developer checklist of applicable criteria and relevant techniques," the link to "HTML techniques" is a 404. {Anna Belle, 4 Sept. 2014}
- All links have been implemented with relative rather than absolute URIs. This was done to make the transition from GitHub to live a bit easier. {Kevin, 5 Sep}

[Done, Kevin, 5 Sep]: I have a little concern over this description in the second sentence:
"As with other important aspects of website development, such as security or maintainability, accessibility is best approached as an aspect of good practice and as an ongoing activity."

I believe that the description dilutes somewhat the message we probably want to convey. Whilst I understand that the reason is not to make accessibility sound "forceful", I think it is important at this point (the first paragraph and, therefore, a relatively important position) to convey a more solid message.

Thus, in this first paragraph, I'd prefer to transfer a message that accessibility is more than just an "aspect of good practice". Probably, this has been discussed extensively but is it at all possible to modify this sentence so that accessibility is best approached within the global framework of compliance to standards and as an ongoing activity?

Suggested change:

"As with other important aspects of website development, such as security, corporate design, maintainability, accessibility is best approached within the framework of compliance to standards and as an ongoing activity." {Vicki, 5 Sep}

[Done, Kevin, 8 Sep]: After heading 2 "Establish Roles and Responsibilitie" there is an heading 4: "Example responsibilities" H3 is missing. {Sylvie Duchateau, 5 Sep}

[Done, Kevin, 8 Sep]: Paragraph concerning:
"Assign responsibility to other organizational areas that impact on the provision of accessible websites."

Suggestion: Is it possible to add "information technology" as part of the areas which will impact accessible sites since IT is an active party in the selection and deployment of tools. {Vicki, 5 Sep}

[Done, Kevin, 8 Sep]: Paragraph heading: "Identify and document the project accessibility goals." change: "This helps to focus your team, clarifies what activities need planned, " to "This helps to focus your team, clarifies what activities need to be planned, " {Vicki, 5 Sep}

[Done, Kevin, 8 Sep]: Paragraph heading: "Establish Roles and Responsibilities". Sentence: "Identify and appointing individuals who are responsible for accessibility ensures that any accessibility related issues are not neglected and that everyone on the team knows where to take accessibility questions." Suggested change: "By identifying and appointing individuals who are responsible for accessibility ensures that any accessibility related issues are not neglected and that everyone on the team knows where to take accessibility questions." {Vicki, 5 Sep}

[Done, Kevin, 8 Sep]: Paragraph heading: "Develop and Implement Organizational Policy". This sentence is incomplete: "Existing policies will also help understanding and view of accessibility." {Vicki, 5 Sep}

[Done, Kevin, 8 Sep]: Paragraph heading: "Assess Skills and Deliver Training" change: "The ability to create an accessible website is larger dependent on the skills and expertise " to: "The ability to create an accessible website is largely dependent on the skills and expertise" {Vicki, 5 Sep}

[Done, Kevin, 8 Sep]: Paragraph: "Assess Skills and Deliver Training" Sentence: "Technical, design, and content creation staff will need to have both a good awareness of the need for accessible solutions" Suggested change: "Technical, design, and content creation staff will need to have both a good understanding of the need for accessible solutions" {Vicki, 5 Sep}

summary — comment {name, date}

Open Comments from Previous Reviews

Introductory and throughout — I shared the draft document with accessibility consulting colleagues today. Their feedback was tremendously insightful and it seemed useful enough to want to share. What is missing is the sense that accessibility is a state of mind even more than it is a process. The fact that accessibility must be integrated, must be iterated, and is never really "done". We should be able to convey this without scaring people. We want to avoid making it seem to be a never-ending task of course but we need to make a stronger case to remain ever mindful of accessibility in every aspect of a project life cycle. My friend said that even though there is a disclaimer that "This does not suggest a fixed order...," the very order and linear nature of the presentation does in fact suggest exactly that. And the final section title "Maintain and Monitor" seemed deadly to her - a kind of brush off my hands and voila, I'm done! it is exactly aligned with waterfall development methodology and makes no provision for how to incorporate accessibility in a more agile workflow. I pass these observations along for your consideration because they resonate with me and I think the document will be improved by addressing those concerns. {Sharron, 27 Aug 2014}
Mostly good, needs tersification in many places but I expect that to come. {Sharron, 20 Aug}
Overall — Mostly quite good, with the expectation of further tersification as the edit progresses. {Sharron, 20 Aug}
+1 to Sharron (and also noting a few spelling & grammatical errors) {Andrew, 2014.08.22}

Past Reviews (Archived)

Superfluous or Missing Guidance

Are any points made not essential for the purpose of the document (please provide examples)?

[Done, Kevin, 22 Aug]: opening introductory section — I don't think this is the place to send people off before they have had a chance to know what is here. "Additional guidance is available if you are looking at Improving the Accessibility of Your Website." {Sharron, 20 Aug}
- This was a hangover from the previous document, with the links in the side there is little value in trying to pull it out too much
[Done, Kevin, 3 Sep]: Introductory section — The very first sentence ("incorporating accessibility...") feels superfluous to me, almost like it was added after everything else had been written. I'd remove it. {Paul, 21 August 2014}
- I am keen to keep this as it avoids the 'This document tells you...' type start which I feel is too dry and doesn't serve to connect with the reader well. Do others have thoughts on this? {Kevin, 26 August 2014}
- I'd prefer the introduction to be even "juicier," but going much further than what you've already written would be unlike the rest of the W3C documentation I've read. I'd introduce a positive word or two like "beneficial and rewarding task" or something similar. Anything more than that is getting into edgy territory ;-) {Paul, 28 August 2014}

Are points NOT made that are essential for the purpose of the document (please provide examples)?

Introductory and throughout — I shared the draft document with accessibility consulting colleagues today. Their feedback was tremendously insightful and it seemed useful enough to want to share. What is missing is the sense that accessibility is a state of mind even more than it is a process. The fact that accessibility must be integrated, must be iterated, and is never really "done". We should be able to convey this without scaring people. We want to avoid making it seem to be a never-ending task of course but we need to make a stronger case to remain ever mindful of accessibility in every aspect of a project life cycle. My friend said that even though there is a disclaimer that "This does not suggest a fixed order...," the very order and linear nature of the presentation does in fact suggest exactly that. And the final section title "Maintain and Monitor" seemed deadly to her - a kind of brush off my hands and voila, I'm done! it is exactly aligned with waterfall development methodology and makes no provision for how to incorporate accessibility in a more agile workflow. I pass these observations along for your consideration because they resonate with me and I think the document will be improved by addressing those concerns. {Sharron, 27 Aug 2014}

Level of Detail

Are any points made insufficiently explained (please provide examples)?

[Done, Kevin, 22 Aug]: Determine Goals...(discussion) — We say that "Obtaining and documenting commitment, ideally by more senior management..." is important but don't provide detailed discussion of what that means or how to do it. Suggestion: either provide more detail or link to a Related Resource like the one in the Business Case. {Sharron, 20 Aug}
- I have connected this sentence to the previous sentence which outlines the use of business case. I have not linked directly in the content but left the link in the Related resources section
[Closed, Kevin, 29 Aug]: Develop...Policy (discussion) — This is good, especially like the tie-in to existing policy of inclusion, diversity, etc {Sharron, 20 Aug}
[Done, Kevin, 4 Sep]: Review Tools... (discussion) — why the call-out of PDF? {Sharron, 20 Aug}
- I wanted to emphasis that content is not simply webpages but could include other, often overlooked, document types {Kevin, 22 Aug}
- So maybe we should mention other files too, e.g. mutimedia, that also get forgotten about sometimes {Andrew, 2014.08.22}
- I have included 'video' to highlight that there are others. Do you think it needs an extensive list or are the two options sufficient? {Kevin, 26 Aug}
[Done, Kevin, 26 Aug]: ...Training (Related References) — Why no reference to Tutorials? {Sharron, 20 Aug}
[Done, Kevin, 22 Aug]: Integrate into Life Cycle...(discussion) — Is this a place where it would make sense to reference the WCAG Techniques? {Sharron, 20 Aug}
[Closed, Kevin, 29 Aug]: Share...(resources) — What about suggesting that staff identified with accessibility be encouraged to participate in WAI-IG List and WAI-Engage wiki? {Sharron, 20 Aug}
[Closed, Kevin, 29 Aug]: Overall — Only the sections without related resources (Share Knowledge and Outcomes, Maintain and Monitor). I've seen blog articles about these topics, but in my experience they tend to be anecdotal and/or too specific. Examples of this information might be a little hard to come by because it describes internal organizational processes. {Paul, 21 August, 2014}

Are any points made explained in too much detail (please provide examples)?

[Done, Kevin, 26 Aug]: Roles/Responsibilities (discussion) — When expanded, the detail of the organizational structure is good - and really negates the need to list them all in Key Actions. {Sharron, 20 Aug}

Tone and Editorial Style

'What do you think about the writing style and tone overall?

Mostly good, needs tersification in many places but I expect that to come. {Sharron, 20 Aug}
[Closed, Kevin, 29 Aug]: Overall — Reads like a playbook for an accessibility evangelist or project manager whose major deliverable is an accessible interface. Language is very action-oriented and practical. {Paul, 21 August 2014}

Are sentence structures mostly easy to follow (please provide examples)?

[Done, Kevin, 22 Aug]: Key Actions — I strongly support the inclusion of "Key Actions" in each section. They are important and are mostly done quite well. In a few cases, however, they could be more direct and less compound. So, for example in Determine Your Goal... could "Identify and document the project goal with regards to accessibility." be replaced with "Identify and document project accessibility goals?" in Establish Roles... could "Consider what organizational areas might impact on the accessibility of the project, such as human resources, procurement, marketing, organizational executive, legal, and ensure they are aware of their role and responsibilities." be replaced with "Ensure that all organizational areas are aware of their responsibility for accessibility implementation as it relates to their job role"? and so forth. The detail can be expanded upon within the Discussion area. I suggest rereading the Key Actions with a strong bias for tersification. {Sharron, 20 Aug}

Are sentences mostly too brief, too wordy, or just right (please provide examples)?

Overall — Mostly quite good, with the expectation of further tersification as the edit progresses. {Sharron, 20 Aug}
+1 to Sharron (and also noting a few spelling & grammatical errors) {Andrew, 2014.08.22}

Title and Expectation setting

How clearly does the title reflect the document?

[Closed, Kevin, 29 Aug]: It's very clear and good in the grey passive way of the W3C. I guess the point last week that we are not Smashing magazine and have another mission is one to remember here. The title says what it is and that is a good thing. I wish it could be a bit more engaging, something like Web Accessibility - Making it Happen. {Sharron, 20 Aug}
[Closed, Kevin, 29 Aug]: I agree with Sharron {Paul, 21 August, 2014}
[Done, Kevin, 26 Aug]: Not sure where to put this comment, but since it's about the title, here goes.... I thought we had agreed to "Implementing Web Accessibility Across Organizations and Projects" -- not "Implementing Accessibility Across Organizations and Web Projects." With this change, I went from disappointed about not using a subtitle to hating the new title. Sorry. I know my reaction is extreme. :-) I heard all the back and forth trying to jigger the subtitle so it works -- so I get it why we decided not to do this. It felt like a stalemate to me. But in expanding the title, why move the word "Web"? The way the title reads now we could be advising on things like building planning (e.g. how to do a wheelchair ramp). {Anna Belle, 26 August, 2014}
- Sorry, you are absolutely right. I have modified to match what is in the meeting summary {Kevin, 26 Aug}

How well does the introduction set expectations for the reader?

[Closed, Kevin, 29 Aug]: Intro is excellent with the small caveat mentioned above about being sent away in the second paragraph. But it sets expectations well. {Sharron, 20 Aug}

How well does section heading text - Key Actions, Discussion, Related Resources - set expectations for the reader?

[Closed, EOWG, 22 Aug]: This too is mostly good, but I am vaguely dissatisfied with "Discussion" as a heading, a topic that Helle raised a few weeks ago. Can we consider what this information is meant to do? Surely we want more than discussion, isn't this the meat of the article, more detail about what and how to make it happen in institutions of various sizes and accessibility awareness? Brainstorming at the 8 Aug EO meeting included these ideas:
- considerations
- aspects,
- details, detailed guidance
- diving deeper
- the full scoop
- applied knowledge
- more info
- applying these points
- ideas into action
- Skills Application
- deeper understanding
- implementing

[Closed, EOWG, 22 Aug]: Has there been any thought about these and the need to specify more clearly what the hidden information will deliver? {Sharron, 20 Aug}

[Closed, EOWG, 22 Aug]: To the brainstorming list above, maybe "approaches" instead of "Discussion"? {Paul, 21 August, 2014}
[Closed, Kevin, 29 Aug]: All the 'related resources' (OK as heading) seem to currently go non-existent Gihub pages {Andrew, 2014.08.22}
- The links are all coded as relative URIs rather than absolute. When it moves to it's live home these should all resolve correctly. {Kevin, 26 Aug}

Personas

Do the characteristics provide an adequate description of the key points to consider?
Do the personas provide sufficient coverage for the potential audiences? or are there some key types of users that are missing?
Are the needs complete or are there additional needs related to information to be provided?
Where two or more personas have a shared or similar need, would the information they require be identical or would there need to be slight variations?
How could type of organisation (e.g. government, corporate, non profit, educational) impact on information provided?

Outline of resources in development

(for later)

What do you think of the outline of the Implementation Plan, Organizational Policies and Improving Existing Sites pages? Are there any missing elements?
There are some initial notes on the content that would be required in each of these sections. What do you think of the initial ideas? What additions could be made?
The Improving page will have a considerable overlap with the Implementation Plan page. Should we simply include these in the introduction?
What thoughts are there on changing the name from 'Implementation Plan for Web Accessibility' to 'Planning for Web Accessibility'? The question is raised as 'Implementation Plan' may not be a widely used term and it may suggest a specific outcome rather than the general advice.
Should these resources be providing guidance and information on planning an accessible website delivery or is there an element of organizational transformation as well?

Personas

I'm confused by the use of "personas" here. Reading the current version of the implementation plan I don't see them even mentioned. Where exactly do they fit it? Where and how will they be used? {Howard, 2014-Jun-19}
- The personas were developed from the initial use cases that were prepared. The aim was to provide a shared understanding for who might use the planning resources and what they would want from them. One thought to use them going forward is that they become a type of navigation item. The use case would be someone visits the section, sees a persona description that is similar to their situation and accesses a subset of the full resource that is pitched to the persona and, by extension, their needs. {Kevin, 2014-Jun-30}
Also, their use conflicts with my understanding of how personas are normally used. Personas are used to create a archetypal user who you can use to interact with your site. In other words, they're a tool for interaction design. I don't see these personas fitting this purpose. {Howard, 2014-Jun-19}
- Yes, personas are often used as an interaction design tool. They can be more broadly used as a tool for understanding user needs and behavior. Those needs could be delivered through interaction or, as in this case, through information. {Kevin, 2014-Jun-30}
Comment {Name, 2014-Jun-XX}

Outline of resources in development

Q4: Not sure if you wanted comments yet on these questions but I prefer 'Implementation Plan for Web Accessibility' because it's much more concrete - I have much more of a sense of what to expect than with 'Planning for Web Accessibility,' which I find too general. True, it does imply a specific outcome but not sure if that's a problem. {Howard, 2014-Jun-19}
Comment {Name, 2014-Jun-XX}

Specific questions

For the questions below, see background and initial ideas in EOWG telecon 8 Aug minutes

Float right text chuck

Should we avoid the right floated examples block in ‘Establish Roles and Responsibilities’?

summary — comment {name, 00-Aug-2014}

Discussion heading

What are the possible alternatives to ‘Discussion’ that are more action oriented, for example, Ideas into Action?

summary — comment {name, 00-Aug-2014}

Buy-in wording

Is ‘Buy-In’ in the ‘Determine Goal and Promote Buy-In’ section appropriate for translation? Is there a better word or would it be appropriate to explain the word in the first part of this sections discussion?

Modified to remove the word 'Buy-In' — I reviewed this section and the subsequent section on Organizational Awareness. It made more sense to change the 'Organizational Awareness' section to be titled 'Share Knowledge and Outcomes' as that was more what was being discussed. This allowed for use of the phrase 'Promote Awareness' instead of 'Buy-In', which is a bit clearer. {Kevin White, 14-Aug-2014}
summary — comment {name, 00-Aug-2014}

Establish Responsibilities

Comments by {Jonathan Metz, 24 jul 2014}:

My approach to accessibility planning and implementation is a bit different than what how it was organized here. Since I don’t know if there was an agreed upon methodology that was decided we should be recommending prior to my arrival to this committee, I apologize for suggesting my approach.

In my opinion, organizations interested in implementing accessibility should organize their approach in a way that snowballs to a conclusion of awesome accessibility. How they arrive at that ultimate end-goal is up to the type of project management philosophy they adhere to, their corporate or organizational structure, and other factors totally out of our control here in EO. However they opt to get to that goal, the functional steps involved might be better addressed if more or less followed a certain way:

determine the level of accessibility expertise currently in the organization
develop or borrow an accessibility policy
understand the level of accessibility currently met or exceeded and where improvement is needed
decide how much effort is intended to be implemented on an organizational level
determine the accessibility requirements based on scale of desired implementation
determine responsibility functions for each assessed requirement based on improvement areas
assign roles based on functions
implement accessibility based on policy and organizational level of effort.
measure performance and evaluate areas needed for improvement to constantly change the situation.
rinse and repeat.

The following recommendations are based more or less on steps 5-7 and touch on steps 4, 8, and 9 respectively above:

Assigning functions based on specific needs that are determined based on evaluating which level of accessibility requirements are needed can help to identify and assign roles that are responsible for accessibility. Identifying and appointing ~~individuals~~roles that are responsible for accessibility is an important ~~part of the successful delivery of~~step toward successfully delivering accessible ~~websites~~ web content (Since many organizations apply WCAG to more than just web content, we might want to consider avoiding language seeming to focus on web sites) ~~and~~as well as promoting, strengthening or improving ~~in bringing about~~ organizational change. ~~They~~ There are many functions of these roles that must be considered in order to ensure ~~that any~~ accessibility ~~project~~ issues are not neglected and ~~that everyone on the team knows where to take accessibility questions~~ various stakeholders understand the functions they are required to manage.

Being responsible for the accessibility on a project involves a range of functions. ~~What it does not mean is that you must enact appropriate solutions and policies yourself.~~ I'm not sure I can agree with this statement. Depending on the size of the organization, or the assessed needs, or the role an individual has adopted might actually make a case for this person enacting solutions and policies. Depending on a number of factors including your goals, your organization’s goals, and the size of your organization, ~~the responsibilities~~ might extend throughout your organization and include more than one individual, team, department or division~~, or be confined to your project team~~.

Determining functions to assign to roles involve addressing two essential aspects. When determining roles, exploring two essential concepts, Communication and Tracking, can be helpful in order to assign functions. Depending on which factors were extrapolated from assessed needs, the requirements of these concepts might be as easy as ~~One of the key responsibilities is to track and communicate the progress of the project. For single websites this may be as simple as~~ maintaining a list of identified accessibility issues as part of broader Quality Assurance (QA) issue tracking activities. For larger projects or where the goal includes an element of organizational change there is will most likely be a need for broader communication and coordination.

At this point it might be worthy to break down criteria of those individual aspects a bit and explain it here. The following list provides examples of other activities that might be important to consider:

Executive presentations of progress and business value of accessibility

Regular communication between regional and departmental accessibility teams

Ongoing review and sharing of new accessibility techniques

Review and revision of policies and processes

Sharing project successes throughout the organization

Identify and respond to accessibility training needs

Manage and procure accessibility audits and testing

In my opinion, the roles of implementing accessibility are different from the job roles. The Example responsible roles in the sidebar seem to be more about identifying job descriptions. I see potential flaws in this approach. Laypeople reading this document might attempt to align their current job structures to specific examples provided instead of assigning broader roles to particular entities.

I see roles as identified larger responsibilities of particular entities. For example, with Agile Project Management, there is a SCRUM master role, but this does not necessarily mean a job title. Instead, I believe we should promote an idea of assigning a generic role that has a benefit of being applied to any position. Determining which position in one’s organization will involve addressing the level of enforcement required based on the specific functions.

Roles should be determined based on how intensive the requirements are of specific functions. Once they’re determined, Roles should be assigned to an entity that has whatever power is needed to perform those functions.

For example, a Production Artist or intern might have a role that involves basic grunt work, following corporate guidelines set in place by upper management, or functions that don’t require a lot of decisions. Functions assigned to this Role are extremely low level.

Someone with a bit more pull in an agency might be taking on more functions that require essential decision making.

I get the impression based on maintaining a separate document for personas that they might serve as illustrations or examples of supportive documents such as Planning and Managing (P&M), Web & Business Case (WBC), and perhaps others. I wonder if the personas might be better suited if they were integrated directly into the Planning and Management document, and ideally integrated within the supporting documents as well. This would provide a consistent illustration that conceptually would strengthen the illustrative approach we are using when explaining material.

For example, the Example Responsible Roles might be better represented using personas instead. Without going into too much detail about their situation since we're only talking about Roles here, perhaps this instead (I used letters as placeholders):

Example Roles based on Individual Functions

HIbah is brand manager for a number of customer facing sites and services for a large organization. She has some experience with accessibility and considers it an important part of her workflow. However, Hibah has an impression that she will need to convince her management team of the value of accessibility to allow project budgets to extend. Based on her evaluation of her needs, she determines her functions to include B, F, K and P. Since Hibah is in a large organization and she is only a manager, she probably only has a Medium Role. Organizations implementing accessibility will want to keep in mind the likelihood that she is not going to be able to enforce a lot of change so the functions assigned to her should reflect this.

Cedric is a development manager of a small team of developers within a medium sized organization. As design work will be outsourced, he needs to manage the concerns of senior management regarding accessibility of both internal and external work. Based on his role with the company managing both internal and outside help, he assesses his functions to be A, B, N, and P as well as F, R, and X, Y, Z. Based on Cedric’s position in the company, he has a Medium to High Role based on the requirements and the amount of people in the company.

Megumi is the Head of Digital Propositions. Responsible for all customer facing web services, she is conscious of accessibility requirements and recognizes the benefits of going beyond specification. Unfortunately she must continually remind the board and third party vendors of both external and internal accessibility requirements. Her functions include A, B, M, N, and O. Like Hibah, Megumi is also in a large organization. But she will probably have a better time enforcing policy surrounding the implementation of accessibility. Therefore she probably has much higher level Role.

Jani, a small business owner, is responsible for ensuring that any agency delivered website meets your desired level of accessibility. As Jani is responsible for ensuring that any agency delivered website meets a specific level of accessibility, she has determined her functions include A, B, D, and F. As Jani is the top dog in the company (Heck, she owns it), she will have the highest level of responsibility, but the role she assigns herself don’t necessarily reflect that. We might want to consider emphasizing that roles and responsibilities don’t necessarily have to be assigned to positions that have ability to enforce as long as they have the support those positions need from upper management.

Svetla, an independent UX designer who is keen to address the low accessibility awareness within her client's corporate structure. Based on identifying the assessed accessibility needs of her client, her functions include: A, D, F, E, etc. Assuming Svetla is an outsourced Accessibility Subject Matter Expert (SME), she has an ability to perform functions on her own in addition to adhering to other organizations policy. Based on the position of being an SME, her role might change accordingly. Another area we might want to address would be that Roles do not necessarily need to be static assignments and they can change based on the specific needs of that position. This would help us to make this guide appropriate for different project management styles.