Re: Co-ordinating feedback

I pinged Shawn about the Google sheet I set up, which is a spreadsheet with
no merging so no barriers to accessibiltiy in the content layout.

tinyurl.com/jmo9st4

In terms of Accessibility of Google sheets Shawn from Google shares this....


David,

Sheets (as with the other editors) works fairly well with screen readers,
but does require a little setup - hopefully our documentation on Screen
reader support for Docs editors
<https://support.google.com/docs/answer/6282736?hl=en> and how to Edit
spreadsheets with a screen reader
<https://support.google.com/docs/answer/1632199> will help? Sheets has a
massive amount of keyboard shortcuts
<https://support.google.com/docs/answer/181110>, too. :-)

Roger, another Googler working on Apps, made a few getting started videos,
like this video one for Sheets
<https://www.youtube.com/watch?v=oCYT63b_m88&feature=youtu.be> (NVDA, but
still should prove helpful - pretty much the same experience with JAWS).

Hope that helps! Definitely use whatever tool makes sense for everyone - I
can totally understand the desire to avoid taking the extra time to learn
another tool just in order to do the work one wanted to do in the first
place.

Regards,

Shawn

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*
Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Wed, Dec 7, 2016 at 3:09 PM, Michael Cooper <cooper@w3.org> wrote:

> On 07/12/2016 4:40 AM, Alastair Campbell wrote:
>
> > Could you set this up in a wiki or some other highly accessible
> application that will at least generate proper HTML table markup?
>
>
>
> Hi Jason,
>
>
>
> Sure, it was the concept rather than format I was worried about. The only
> thing is that wiki format for tables is really delicate, so having lots of
> people edit the same page could lead to some terrible markup!
>
> Before launching in on this (and having had sleep now), perhaps I should
> give github a chance? (Nudging *Michael*, who thought we might be able
> enabled editing of the issue by the assignee.)
>
> I want to talk through options with the chairs and come back with a
> proposal. I think editing the issue directly has some problems:
>
>    - It seems you have to have owner access to be able to edit the
>    original issue, if you're not the one who filed it. Typically we don't give
>    owner access to so many people.
>    - Editing the original issue destroys history, as I don't think GitHub
>    archives old versions for issues.
>    - Issues are probably not the best way to store the richer structure
>    we're using anyways. It works, but when it gets time for editing I think
>    it's complex.
>
> An alternate proposal has been to simply add new versions of the SC as new
> comments on the proposal. That preserves history but will make it hard to
> follow the comment thread I think.
> I think we need to come up with another approach - put the SC in the wiki
> and have the issue point to it, or set up a way to edit the SC as
> individual pages within GitHub and have the issue point to those. That in
> turn might require us to set up branches, protect the working branches,
> etc. I plan to discuss this with the chairs tomorrow and see if we can come
> up with something we think will work.
>
>
>
> The concept was to make sure some people were looking at each SC, draw a
> line under a round of reviews, and have a new round with refined SCs.
>
>
>
> In github terms I think that would mean:
>
> -          Setup a milestone (perhaps “Review round 1” or similar), set
> all current issues to that milestone;
>
> -          Direct people to review SCs with the least comments [1];
>
> -          If reviewers are happy with the SC (or a revised version in
> the comments), they add a positive comment to say so.
>
> -          If reviewers think there are issues, add comments about that.
>
> -          The SC manager can rebut the comments or refine the SC in the
> comments.
>
> -          SCs which need discussion are raised as agenda items for the
> weekly call. (E.g. I would raise the contrast one for next week, as there
> is a critical concept that needs to be accepted for it to work.)
>
> -          Once every SC has comments or thumbs up from (say) 5 people,
> we start a new milestone.
>
>
>
> I’m not sure if it would be best to setup new issues for each SC and close
> the old one, or transfer them across milestones? I suspect it would be best
> to start a new issue for the SC, and link back to the previous one at the
> top for historical discussion, but we could probably do either on a case by
> case basis depending on how different the SC is at the end of the round.
>
>
>
> It is also possible to construct searches such as: every SC I haven’t
> commented on, which will help spread it around.
>
> On the whole this proposal for process sounds good.
>
>
>
> My github-foo is not strong, especially around how milestones work, so
> this is only an idea. Does it seem reasonable?
>
> My github-foo isn't the greatest either, but I can say a little. I'm not
> sure if the milestones feature really helps us, because GitHub only counts
> an issue towards having reached the milestone when the issue is closed. If
> we're expecting various review rounds, that might not be the process we
> want. It might be that tags serve better, or that we'll have to do some of
> the progress tracking outside of the GitHub interface. Andrew loves
> spreadsheets...
>
> Michael
>
>
>
> Cheers,
>
>
>
> -Alastair
>
>
>
> 1] https://github.com/w3c/wcag21/issues?q=is%3Aissue+is%3Aopen+
> sort%3Acomments-asc
>
> 2] Everything I haven’t commented on is: “is:issue is:open
> -commenter:alastc”
>
>
>