w3c/wbs-design
or
by mail to sysreq
.
The results of this questionnaire are available to anybody. In addition, answers are sent to the following email addresses: shawn@w3.org,shadi+EOsurvey@w3.org
This questionnaire was open from 2016-01-22 to 2016-02-04.
12 answers have been received.
Jump to results for question:
summary | by responder | by choice
Please read the 22 January EOWG teleconference meeting minutes. Indicate your approval or concerns with the resolution(s) passed at that meeting. The summary and the link to the full minutes is on the 2016 Minutes wiki page.
Choice | All responders |
---|---|
Results | |
I was in the teleconference and I'm OK with them! | 9 |
I have reviewed the minutes and agree to the Resolutions passed. | 3 |
I have reviewed the minutes but have concerns with the Resolutions, and I explain them below. | |
I have not read the minutes yet, and have put the date for my review into the comments box. |
Skip to view by choice.
Responder | Resolutions of 22 January | Comments |
---|---|---|
Vivienne Conway |
|
|
Shawn Lawton Henry |
|
|
Eric Eggert |
|
|
Anna Belle Leiserson |
|
|
David Berman |
|
|
James Green |
|
|
George Heake |
|
|
Susan Hewitt |
|
|
Howard Kramer |
|
|
Sharron Rush |
|
|
Andrew Arch |
|
|
Brent Bakken |
|
Choice | Responders |
---|---|
I was in the teleconference and I'm OK with them! |
|
I have reviewed the minutes and agree to the Resolutions passed. |
|
I have reviewed the minutes but have concerns with the Resolutions, and I explain them below. | |
I have not read the minutes yet, and have put the date for my review into the comments box. |
summary | by responder | by choice
The Developing Organizational Policies on Web Accessibility document is related to the content in the Planning and Managing Web Accessibility resource.
Please undertake a thorough review of this page and report any issues with the content. Also, consider how this resource fits with and supports the Planning and Managing resource.
Please add any comments in GitHub as new issues or pull requests. If you are not comfortable with GitHub, please add your comments below.
Choice | All responders |
---|---|
Results | |
I completed a thorough review of the document and have added comments or issues in GitHub or in the comment section below. | 7 |
I will complete a thorough review of the document by the date in the comment section below. | 2 |
I didn't get to it; I will pass on commenting on the document and accept the decisions of the Group. | 2 |
(1 response didn't contain an answer to this question)
Skip to view by choice.
Responder | Planning: Policy document review | Comments |
---|---|---|
Vivienne Conway |
|
I have read this document and do not see any new issues at the moment that should be added/changed. I will continue to look at this and will advise of any suggestions I can think of. |
Shawn Lawton Henry |
|
|
Eric Eggert |
|
Not too much content-wise from me (but I haven’t been involved in active policy development), but a few nit-picky things (sorry |
Anna Belle Leiserson |
|
Before 2/4/16. I expect my feedback will be only copy editing -- nothing substantive. |
David Berman |
|
|
James Green |
|
|
George Heake |
|
I have no issues. I agree with the content and format. |
Susan Hewitt |
|
Edits in GitHub but overall I'm confused by this document and the one below. It's hard for me to determine how it's different from the planning guide and I imagine it would be even more so for a user fairly new to accessibility planning. |
Howard Kramer |
|
I thought it looked good. The only concern I had was the first part - reference standards. It seems like we're directing folks out to these very large resources but unlike the other sections below, there's no example on how they might be used. |
Sharron Rush |
|
Feb 6th |
Andrew Arch | The sentence "This document guides your development of a web accessibility policy that works within the context of your specific environment." implies the reader will develop the policy. This may or may-not be the case, so suggest "This document guides your organization's development ..." The 'simple policy' examples references WCAG 2.0, but the following text suggests starting simple and then expanding, including referencing standards! Maybe we should simplify the example further? The Reference Standards section does not include WAI-ARIA - this is probably more relevant to most organisations that UAAG. The emphasis is on web-content rather than an interactive/transnational site. (While 'content' technically interludes interactions, it is often interpreted as static informational content.) The page does not recognise the inherent difference in upgrading informational content vs interactive content - different milestones might even be needed (and even need to be adjusted as work progresses - partly addressed in "Define Monitoring and Review Process"). Also, let's reset the dates to somewhere in the future :) Wonder if there should be a section about third-party tools (e.g. HR system, shopping catalogue and basket, payment systems) all of which are part of customers experience on your sites, but which might be beyond your control from an accessibility upgrade perspective (and often can't just be ditched and replaced easily). This aspect seems to be covered in the 'policy template', but not discussed in the 'third party content' section. | |
Brent Bakken |
|
# Opening summary statement: "To learn about how an organizational policy forms part of a broader approach to implementing accessibility, read Planning and Managing Web Accessibility." The link to Planning and Managing... goes to the wrong resource at this time, will it be correct when Planning and Managing is complete and approved? # ATAG - add word: "ATAG guidelines outline both how to make the tools [themselves] accessible and also how the tools can be built to help create more accessible content." # UAAG - typo: "Find out more at ATAG Overview" should be "Find out more at [UAAG] Overview" # Set Conformance Milestones - edit: "For all items in scope, define a date by which it will meet the policy, or if it already meets the policy, identify when it was last reviewed. # Next Steps: Maintaining your policy - What to consider: "Determine if policy scope needs to be adjusted due to new content or significant changes to structure of web site." (or something to that effect. |
Choice | Responders |
---|---|
I completed a thorough review of the document and have added comments or issues in GitHub or in the comment section below. |
|
I will complete a thorough review of the document by the date in the comment section below. |
|
I didn't get to it; I will pass on commenting on the document and accept the decisions of the Group. |
|
summary | by responder | by choice
The Improving the Accessibility of Your Website document is related to the content in the Planning and Managing Web Accessibility resource.
Please undertake a thorough review of this page and report any issues with the content. Also, consider how this resource fits with and supports the Planning and Managing resource.
Please add any comments in GitHub as new issues or pull requests. If you are not comfortable with GitHub, please add your comments below.
Choice | All responders |
---|---|
Results | |
I completed a thorough review of the document and have added comments or issues in GitHub or in the comment section below. | 6 |
I will complete a thorough review of the document by the date in the comment section below. | 3 |
I didn't get to it; I will pass on commenting on the document and accept the decisions of the Group. | 2 |
(1 response didn't contain an answer to this question)
Skip to view by choice.
Responder | Planning: Improving document review | Comments |
---|---|---|
Vivienne Conway |
|
|
Shawn Lawton Henry |
|
4 Feb |
Eric Eggert |
|
Just one minor thing: https://github.com/w3c/wai-planning-and-implementation/issues/40 Also, I can see that this is a lot of text – I think a **future** version might have each section on its own page and probably even expand on the individual issues with more concrete example. I personally found the document hard to skim and it is also a bit weird when the “key actions” are shorter than the introductory sentences. I think that a **future** version of the document might be more actionable and tersify the introductory text. |
Anna Belle Leiserson |
|
Before 2/4/16. I expect my feedback will be only copy editing -- nothing substantive. |
David Berman |
|
|
James Green |
|
|
George Heake |
|
|
Susan Hewitt |
|
See above. |
Howard Kramer |
|
I like the examples provided on the Organizational document. Should we do something similar on this resource? |
Sharron Rush |
|
Feb 6th |
Andrew Arch |
|
29/Jan - "wide-spread network disruption" affecting my review |
Brent Bakken | # Opening summary statement: "For guidance on how to succeed in that long term goal, you will want to read WAI's Planning and Managing Web Accessibility." The link to Planning and Managing... goes to the wrong resource at this time, will it be correct when Planning and Managing is complete and approved? # Prioritize Solutions - Key actions: Could we possibly provide an example of a matrix that shows impact vs effort of issues for a sample site. I think the matrix is a powerful visual tool for leadership and an example here would demonstrate that. # Implement Repairs - edit: "For each issue to be fixed, ensure that it is clear who [will] do the work[,] and that they have the appropriate skills or knowledge." # Review Achievements - edit: "Once repairs are completed, review what has been achieved and what is still left to be [addressed]." # Long Term - Strategic Planning - edit: "There are several things you can do to help your organization routinely create more accessible websites." |
Choice | Responders |
---|---|
I completed a thorough review of the document and have added comments or issues in GitHub or in the comment section below. |
|
I will complete a thorough review of the document by the date in the comment section below. |
|
I didn't get to it; I will pass on commenting on the document and accept the decisions of the Group. |
|
summary | by responder | by choice
In the future, the Accessible Components Gallery [Working Title] will allow members of the public to submit links to widgets, templates and frameworks to a central repository (“Crowd Sourcing”).
To make sure that the components have a certain level of quality, there need to be some submission rules. The broad outline of those criteria is posted to this wiki page. Please review this Submission Criteria outline and comment in GitHub or in the Comment section below.
It is especially interesting how you search for such components and what your personal requirements are for choosing which component to use in projects.
Choice | All responders |
---|---|
Results | |
I reviewed the submission criteria and added comments in the comment field below. | 4 |
I reviewed the submission criteria but don’t have anything to add at the moment. | 5 |
I didn’t get to it but will answer by the date indicated in the comment field below. | 2 |
(1 response didn't contain an answer to this question)
Skip to view by choice.
Responder | Accessible Components Gallery [Working Title]: Submission Criteria | Comments |
---|---|---|
Vivienne Conway |
|
Should there be a statement in there about how it will be evaluated for inclusion and how notification of the outcome is handled? |
Shawn Lawton Henry | ||
Eric Eggert |
|
[Editor] |
Anna Belle Leiserson |
|
Great start! |
David Berman |
|
Change from passive to active voice. For example, change "Only components that are covered by these three categories can be submitted:" to "Only submit components that belong to one of these three categories:"submitted: Also item 5 is not a requirement, so doesn't belong in a list of requirements. Item 6 should likely be split into two points (one just for advertisements. Change "SPAM" to "spam". |
James Green |
|
|
George Heake |
|
|
Susan Hewitt |
|
|
Howard Kramer |
|
1/28/16 - the wiki was down when I tried to access it this evening. |
Sharron Rush |
|
|
Andrew Arch |
|
29/Jan - "wide-spread network disruption" affecting my review |
Brent Bakken |
|
1) If they do not have a W3C account will they be able to submit components? Do we need to add directions on how to create a W3C wordpress account? #2) Change wording to... "Only submit components that are aligned to the following categories:" Rationale - we may add more categories later, and the wording may let people know that we may be open to more categories if a key one is suggested. #4) Change wording to... "The submitter makes sure that the submission is detailed and accurate. Submission by the creator/developer of a component is preferred." Other) Do we need to make sure that people have checked with the original developer/author of the components for approval to submit and list them on our site? |
Choice | Responders |
---|---|
I reviewed the submission criteria and added comments in the comment field below. |
|
I reviewed the submission criteria but don’t have anything to add at the moment. |
|
I didn’t get to it but will answer by the date indicated in the comment field below. |
|
summary | by responder | by choice
I have updated my availability for EOWG face to face meetings in 2016, especially around the March 21 CSUN conference.
Choice | All responders |
---|---|
Results | |
Yes | 11 |
No | 1 |
Skip to view by choice.
Responder | Face to Face Availability | Comments |
---|---|---|
Vivienne Conway |
|
|
Shawn Lawton Henry |
|
|
Eric Eggert |
|
|
Anna Belle Leiserson |
|
|
David Berman |
|
|
James Green |
|
|
George Heake |
|
|
Susan Hewitt |
|
|
Howard Kramer |
|
|
Sharron Rush |
|
|
Andrew Arch |
|
|
Brent Bakken |
|
Choice | Responders |
---|---|
Yes |
|
No |
|
The following persons have not answered the questionnaire:
Send an email to all the non-responders.
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
w3c/wbs-design
or
by mail to sysreq
.