E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 7 (In chronological order)

From: Marco Zehe
Date: Fri, Jul 03 2015 6:10AM
Subject: Marking up file diffs in a table properly
No previous message | Next message →

Hi everyone, especially those of you who like to juggle data tables!

I have a rather developer-centric issue I'd like to throw out for
discussion there. This concerns how patches, or diffs, are being displayed
in Github, and other tools. At Mozilla, we use a software called Review
Board from https://www.reviewboard.org/. Those have in common that they
display side by side diffs in a tabular fashion. The problem is that all of
these implementations I've seen so far don't give enough semantic
information to screen readers to give a really good experience. But before
I approach Review Board with this, I would like to gather some input to see
if we can better the situation at all, or if current table markup may not
be sufficient.

Here's a review request you can look at, by yours truly:
https://reviewboard.mozilla.org/r/12135/ - This is the general review
request.
https://reviewboard.mozilla.org/r/12135/diff/2#index_header - This is the
complete diff, the interesting stuff starts in the third data table on the
page.

The first few rows of the table contain the file name, and how many lines
there are before the diff starts, with the option to show more context.
Then, a few lines that are identical, and then, line 74 starts where the
first difference occurs. As you can hear if you use this with a screen
reader, the reading of column and row headers is not very nice.
Specifically, the file name from the very top of the table, within the
thead, is repeated over and over again.

Second problem: The old and new files can only be distinguished by their
column numbers (1 and 2 are old, 3 and 4 are new).

And third, it is not immediately obvious if the line was changed, stuff was
removed, added, or edited. The line numbers in both cases are marked as row
header, which *seems* correct, but I would want some more semantics for the
columns at least, and something more useful than just the file name
repeated, at that.

From your experience of working with accessible tables day to day, what
would be the best solution here? Dissolve the single column header with its
col span and put extra column headers with off-screen/collapsed text in it?
Use different column headers for different sections and work with scope,
axis or whatever attributes exist for these cases?

I personally feel a bit overwhelmed with all the possibilities data tables
have to offer, so I thought I'd call out to you ladies and gents for some
ideas/advice/suggestions!

Thanks!

Marco

From: Lynn Holdsworth
Date: Fri, Jul 03 2015 7:28AM
Subject: Re: Marking up file diffs in a table properly
← Previous message | Next message →

Hi Marco,

This is a great implementation compared to most of what's out there.

I don't know how changes are currently flagged up. Using bold perhaps?
Or do users need to work this out for themselves? I'd be happy to do
that, so long as there's some flag to alert me to which lines have
been changed.

It would be very useful if line numbers where changes have occurred
could be preceded by a flag character, perhaps an asterisk: "*75".

Do the lines that sit side by side always have the same number? If so
then for me it would make sense to have a single line number in column
1 rather than having it repeaded in another column, with the original
line of text in column 2, and the new line in column 3. Perhaps the
last two columns could be labelled "Old" and "New" - nice and quick to
listen to if you want to move fast.

As for labelling, if "Old" and "New" could be table headers somewhere
towards the top of the table, perhaps as the first row of the 4-column
layout, this could work well.

This isn't a massively complex table, so screenreaders should be able
to determine the scope accurately enough, but it wouldn't do any harm
to add it anyhow.

Cheers, Lynn

On 03/07/2015, Marco Zehe < = EMAIL ADDRESS REMOVED = > wrote:
> Hi everyone, especially those of you who like to juggle data tables!
>
> I have a rather developer-centric issue I'd like to throw out for
> discussion there. This concerns how patches, or diffs, are being displayed
> in Github, and other tools. At Mozilla, we use a software called Review
> Board from https://www.reviewboard.org/. Those have in common that they
> display side by side diffs in a tabular fashion. The problem is that all of
> these implementations I've seen so far don't give enough semantic
> information to screen readers to give a really good experience. But before
> I approach Review Board with this, I would like to gather some input to see
> if we can better the situation at all, or if current table markup may not
> be sufficient.
>
> Here's a review request you can look at, by yours truly:
> https://reviewboard.mozilla.org/r/12135/ - This is the general review
> request.
> https://reviewboard.mozilla.org/r/12135/diff/2#index_header - This is the
> complete diff, the interesting stuff starts in the third data table on the
> page.
>
> The first few rows of the table contain the file name, and how many lines
> there are before the diff starts, with the option to show more context.
> Then, a few lines that are identical, and then, line 74 starts where the
> first difference occurs. As you can hear if you use this with a screen
> reader, the reading of column and row headers is not very nice.
> Specifically, the file name from the very top of the table, within the
> thead, is repeated over and over again.
>
> Second problem: The old and new files can only be distinguished by their
> column numbers (1 and 2 are old, 3 and 4 are new).
>
> And third, it is not immediately obvious if the line was changed, stuff was
> removed, added, or edited. The line numbers in both cases are marked as row
> header, which *seems* correct, but I would want some more semantics for the
> columns at least, and something more useful than just the file name
> repeated, at that.
>
> From your experience of working with accessible tables day to day, what
> would be the best solution here? Dissolve the single column header with its
> col span and put extra column headers with off-screen/collapsed text in it?
> Use different column headers for different sections and work with scope,
> axis or whatever attributes exist for these cases?
>
> I personally feel a bit overwhelmed with all the possibilities data tables
> have to offer, so I thought I'd call out to you ladies and gents for some
> ideas/advice/suggestions!
>
> Thanks!
>
> Marco
> > > > >

From: Marco Zehe
Date: Fri, Jul 03 2015 7:54AM
Subject: Re: Marking up file diffs in a table properly
← Previous message | Next message →

Hi Lynn,

for sighted people, the lines where stuff is removed, changed or added, are
colored differently I think, and/or different fonts are used.

The line numbers diverge as soon as stuff is removed from the old file, or
new stuff is added to the new. In the blocks further down my example, this
can be observed, as new stuff is added. So the line numbers in column 3
increase gradually whereas the ones on the left fall behind when
side-by-side diff resumes below the new code block.

Marco


2015-07-03 15:28 GMT+02:00 Lynn Holdsworth < = EMAIL ADDRESS REMOVED = >:

> Hi Marco,
>
> This is a great implementation compared to most of what's out there.
>
> I don't know how changes are currently flagged up. Using bold perhaps?
> Or do users need to work this out for themselves? I'd be happy to do
> that, so long as there's some flag to alert me to which lines have
> been changed.
>
> It would be very useful if line numbers where changes have occurred
> could be preceded by a flag character, perhaps an asterisk: "*75".
>
> Do the lines that sit side by side always have the same number? If so
> then for me it would make sense to have a single line number in column
> 1 rather than having it repeaded in another column, with the original
> line of text in column 2, and the new line in column 3. Perhaps the
> last two columns could be labelled "Old" and "New" - nice and quick to
> listen to if you want to move fast.
>
> As for labelling, if "Old" and "New" could be table headers somewhere
> towards the top of the table, perhaps as the first row of the 4-column
> layout, this could work well.
>
> This isn't a massively complex table, so screenreaders should be able
> to determine the scope accurately enough, but it wouldn't do any harm
> to add it anyhow.
>
> Cheers, Lynn
>
> On 03/07/2015, Marco Zehe < = EMAIL ADDRESS REMOVED = > wrote:
> > Hi everyone, especially those of you who like to juggle data tables!
> >
> > I have a rather developer-centric issue I'd like to throw out for
> > discussion there. This concerns how patches, or diffs, are being
> displayed
> > in Github, and other tools. At Mozilla, we use a software called Review
> > Board from https://www.reviewboard.org/. Those have in common that they
> > display side by side diffs in a tabular fashion. The problem is that all
> of
> > these implementations I've seen so far don't give enough semantic
> > information to screen readers to give a really good experience. But
> before
> > I approach Review Board with this, I would like to gather some input to
> see
> > if we can better the situation at all, or if current table markup may not
> > be sufficient.
> >
> > Here's a review request you can look at, by yours truly:
> > https://reviewboard.mozilla.org/r/12135/ - This is the general review
> > request.
> > https://reviewboard.mozilla.org/r/12135/diff/2#index_header - This is
> the
> > complete diff, the interesting stuff starts in the third data table on
> the
> > page.
> >
> > The first few rows of the table contain the file name, and how many lines
> > there are before the diff starts, with the option to show more context.
> > Then, a few lines that are identical, and then, line 74 starts where the
> > first difference occurs. As you can hear if you use this with a screen
> > reader, the reading of column and row headers is not very nice.
> > Specifically, the file name from the very top of the table, within the
> > thead, is repeated over and over again.
> >
> > Second problem: The old and new files can only be distinguished by their
> > column numbers (1 and 2 are old, 3 and 4 are new).
> >
> > And third, it is not immediately obvious if the line was changed, stuff
> was
> > removed, added, or edited. The line numbers in both cases are marked as
> row
> > header, which *seems* correct, but I would want some more semantics for
> the
> > columns at least, and something more useful than just the file name
> > repeated, at that.
> >
> > From your experience of working with accessible tables day to day, what
> > would be the best solution here? Dissolve the single column header with
> its
> > col span and put extra column headers with off-screen/collapsed text in
> it?
> > Use different column headers for different sections and work with scope,
> > axis or whatever attributes exist for these cases?
> >
> > I personally feel a bit overwhelmed with all the possibilities data
> tables
> > have to offer, so I thought I'd call out to you ladies and gents for some
> > ideas/advice/suggestions!
> >
> > Thanks!
> >
> > Marco
> > > > > > > > > >
> > > > >

From: Lynn Holdsworth
Date: Fri, Jul 03 2015 8:37AM
Subject: Re: Marking up file diffs in a table properly
← Previous message | Next message →

Hi Marco,

Yes, sorry - I now see this in action in table 4. I had it in my head
that all the action was happening in table 3.

So how about adding "Old" and "New" after the respective line numbers?
Would that be useful or only create extra noise? You could still have
"Old" and "New" as row headers for the lines of text in columns 2 and
4.

I'd still want at least an asterisk in column 3 to flag up that the
line in column 4 contains changes.

For me personally, trying to structurally flag up what type of changes
have occurred, especially if a line contains different sorts of
change, could cause confusion and thus be counter-productive.

How about if the new line could be a link that opens a more
descriptive version of the changes in a new window? I would probably
open it very rarely, as it would likely be faster just to ahalyse the
two lines myself, but it could be an extra prop if required.

Cheers, Lynn

On 03/07/2015, Marco Zehe < = EMAIL ADDRESS REMOVED = > wrote:
> Hi Lynn,
>
> for sighted people, the lines where stuff is removed, changed or added, are
> colored differently I think, and/or different fonts are used.
>
> The line numbers diverge as soon as stuff is removed from the old file, or
> new stuff is added to the new. In the blocks further down my example, this
> can be observed, as new stuff is added. So the line numbers in column 3
> increase gradually whereas the ones on the left fall behind when
> side-by-side diff resumes below the new code block.
>
> Marco
>
>
> 2015-07-03 15:28 GMT+02:00 Lynn Holdsworth < = EMAIL ADDRESS REMOVED = >:
>
>> Hi Marco,
>>
>> This is a great implementation compared to most of what's out there.
>>
>> I don't know how changes are currently flagged up. Using bold perhaps?
>> Or do users need to work this out for themselves? I'd be happy to do
>> that, so long as there's some flag to alert me to which lines have
>> been changed.
>>
>> It would be very useful if line numbers where changes have occurred
>> could be preceded by a flag character, perhaps an asterisk: "*75".
>>
>> Do the lines that sit side by side always have the same number? If so
>> then for me it would make sense to have a single line number in column
>> 1 rather than having it repeaded in another column, with the original
>> line of text in column 2, and the new line in column 3. Perhaps the
>> last two columns could be labelled "Old" and "New" - nice and quick to
>> listen to if you want to move fast.
>>
>> As for labelling, if "Old" and "New" could be table headers somewhere
>> towards the top of the table, perhaps as the first row of the 4-column
>> layout, this could work well.
>>
>> This isn't a massively complex table, so screenreaders should be able
>> to determine the scope accurately enough, but it wouldn't do any harm
>> to add it anyhow.
>>
>> Cheers, Lynn
>>
>> On 03/07/2015, Marco Zehe < = EMAIL ADDRESS REMOVED = > wrote:
>> > Hi everyone, especially those of you who like to juggle data tables!
>> >
>> > I have a rather developer-centric issue I'd like to throw out for
>> > discussion there. This concerns how patches, or diffs, are being
>> displayed
>> > in Github, and other tools. At Mozilla, we use a software called Review
>> > Board from https://www.reviewboard.org/. Those have in common that they
>> > display side by side diffs in a tabular fashion. The problem is that all
>> of
>> > these implementations I've seen so far don't give enough semantic
>> > information to screen readers to give a really good experience. But
>> before
>> > I approach Review Board with this, I would like to gather some input to
>> see
>> > if we can better the situation at all, or if current table markup may
>> > not
>> > be sufficient.
>> >
>> > Here's a review request you can look at, by yours truly:
>> > https://reviewboard.mozilla.org/r/12135/ - This is the general review
>> > request.
>> > https://reviewboard.mozilla.org/r/12135/diff/2#index_header - This is
>> the
>> > complete diff, the interesting stuff starts in the third data table on
>> the
>> > page.
>> >
>> > The first few rows of the table contain the file name, and how many
>> > lines
>> > there are before the diff starts, with the option to show more context.
>> > Then, a few lines that are identical, and then, line 74 starts where the
>> > first difference occurs. As you can hear if you use this with a screen
>> > reader, the reading of column and row headers is not very nice.
>> > Specifically, the file name from the very top of the table, within the
>> > thead, is repeated over and over again.
>> >
>> > Second problem: The old and new files can only be distinguished by their
>> > column numbers (1 and 2 are old, 3 and 4 are new).
>> >
>> > And third, it is not immediately obvious if the line was changed, stuff
>> was
>> > removed, added, or edited. The line numbers in both cases are marked as
>> row
>> > header, which *seems* correct, but I would want some more semantics for
>> the
>> > columns at least, and something more useful than just the file name
>> > repeated, at that.
>> >
>> > From your experience of working with accessible tables day to day, what
>> > would be the best solution here? Dissolve the single column header with
>> its
>> > col span and put extra column headers with off-screen/collapsed text in
>> it?
>> > Use different column headers for different sections and work with scope,
>> > axis or whatever attributes exist for these cases?
>> >
>> > I personally feel a bit overwhelmed with all the possibilities data
>> tables
>> > have to offer, so I thought I'd call out to you ladies and gents for
>> > some
>> > ideas/advice/suggestions!
>> >
>> > Thanks!
>> >
>> > Marco
>> > >> > >> > >> > >> >
>> >> >> >> >>
> > > > >

From: Marco Zehe
Date: Fri, Jul 03 2015 9:55AM
Subject: Re: Marking up file diffs in a table properly
← Previous message | Next message →

Hi Lynn,

yes, something like "new", "changed" or "removed" could work as extra,
maybe hidden, text for the line numbers I think. I'll wait a bit for other
suggestions from the list, if any, and then put together something to see
how that sounds as a suggestion. or maybe I'l use MozReview as a first
entrance, and then we upstream it to Review Board once we see it working
nicely within our custom install.

Marco


2015-07-03 16:37 GMT+02:00 Lynn Holdsworth < = EMAIL ADDRESS REMOVED = >:

> Hi Marco,
>
> Yes, sorry - I now see this in action in table 4. I had it in my head
> that all the action was happening in table 3.
>
> So how about adding "Old" and "New" after the respective line numbers?
> Would that be useful or only create extra noise? You could still have
> "Old" and "New" as row headers for the lines of text in columns 2 and
> 4.
>
> I'd still want at least an asterisk in column 3 to flag up that the
> line in column 4 contains changes.
>
> For me personally, trying to structurally flag up what type of changes
> have occurred, especially if a line contains different sorts of
> change, could cause confusion and thus be counter-productive.
>
> How about if the new line could be a link that opens a more
> descriptive version of the changes in a new window? I would probably
> open it very rarely, as it would likely be faster just to ahalyse the
> two lines myself, but it could be an extra prop if required.
>
> Cheers, Lynn
>
> On 03/07/2015, Marco Zehe < = EMAIL ADDRESS REMOVED = > wrote:
> > Hi Lynn,
> >
> > for sighted people, the lines where stuff is removed, changed or added,
> are
> > colored differently I think, and/or different fonts are used.
> >
> > The line numbers diverge as soon as stuff is removed from the old file,
> or
> > new stuff is added to the new. In the blocks further down my example,
> this
> > can be observed, as new stuff is added. So the line numbers in column 3
> > increase gradually whereas the ones on the left fall behind when
> > side-by-side diff resumes below the new code block.
> >
> > Marco
> >
> >
> > 2015-07-03 15:28 GMT+02:00 Lynn Holdsworth < = EMAIL ADDRESS REMOVED = >:
> >
> >> Hi Marco,
> >>
> >> This is a great implementation compared to most of what's out there.
> >>
> >> I don't know how changes are currently flagged up. Using bold perhaps?
> >> Or do users need to work this out for themselves? I'd be happy to do
> >> that, so long as there's some flag to alert me to which lines have
> >> been changed.
> >>
> >> It would be very useful if line numbers where changes have occurred
> >> could be preceded by a flag character, perhaps an asterisk: "*75".
> >>
> >> Do the lines that sit side by side always have the same number? If so
> >> then for me it would make sense to have a single line number in column
> >> 1 rather than having it repeaded in another column, with the original
> >> line of text in column 2, and the new line in column 3. Perhaps the
> >> last two columns could be labelled "Old" and "New" - nice and quick to
> >> listen to if you want to move fast.
> >>
> >> As for labelling, if "Old" and "New" could be table headers somewhere
> >> towards the top of the table, perhaps as the first row of the 4-column
> >> layout, this could work well.
> >>
> >> This isn't a massively complex table, so screenreaders should be able
> >> to determine the scope accurately enough, but it wouldn't do any harm
> >> to add it anyhow.
> >>
> >> Cheers, Lynn
> >>
> >> On 03/07/2015, Marco Zehe < = EMAIL ADDRESS REMOVED = > wrote:
> >> > Hi everyone, especially those of you who like to juggle data tables!
> >> >
> >> > I have a rather developer-centric issue I'd like to throw out for
> >> > discussion there. This concerns how patches, or diffs, are being
> >> displayed
> >> > in Github, and other tools. At Mozilla, we use a software called
> Review
> >> > Board from https://www.reviewboard.org/. Those have in common that
> they
> >> > display side by side diffs in a tabular fashion. The problem is that
> all
> >> of
> >> > these implementations I've seen so far don't give enough semantic
> >> > information to screen readers to give a really good experience. But
> >> before
> >> > I approach Review Board with this, I would like to gather some input
> to
> >> see
> >> > if we can better the situation at all, or if current table markup may
> >> > not
> >> > be sufficient.
> >> >
> >> > Here's a review request you can look at, by yours truly:
> >> > https://reviewboard.mozilla.org/r/12135/ - This is the general review
> >> > request.
> >> > https://reviewboard.mozilla.org/r/12135/diff/2#index_header - This is
> >> the
> >> > complete diff, the interesting stuff starts in the third data table on
> >> the
> >> > page.
> >> >
> >> > The first few rows of the table contain the file name, and how many
> >> > lines
> >> > there are before the diff starts, with the option to show more
> context.
> >> > Then, a few lines that are identical, and then, line 74 starts where
> the
> >> > first difference occurs. As you can hear if you use this with a screen
> >> > reader, the reading of column and row headers is not very nice.
> >> > Specifically, the file name from the very top of the table, within the
> >> > thead, is repeated over and over again.
> >> >
> >> > Second problem: The old and new files can only be distinguished by
> their
> >> > column numbers (1 and 2 are old, 3 and 4 are new).
> >> >
> >> > And third, it is not immediately obvious if the line was changed,
> stuff
> >> was
> >> > removed, added, or edited. The line numbers in both cases are marked
> as
> >> row
> >> > header, which *seems* correct, but I would want some more semantics
> for
> >> the
> >> > columns at least, and something more useful than just the file name
> >> > repeated, at that.
> >> >
> >> > From your experience of working with accessible tables day to day,
> what
> >> > would be the best solution here? Dissolve the single column header
> with
> >> its
> >> > col span and put extra column headers with off-screen/collapsed text
> in
> >> it?
> >> > Use different column headers for different sections and work with
> scope,
> >> > axis or whatever attributes exist for these cases?
> >> >
> >> > I personally feel a bit overwhelmed with all the possibilities data
> >> tables
> >> > have to offer, so I thought I'd call out to you ladies and gents for
> >> > some
> >> > ideas/advice/suggestions!
> >> >
> >> > Thanks!
> >> >
> >> > Marco
> >> > > >> > > >> > > >> > > >> >
> >> > >> > >> > >> > >>
> > > > > > > > > >
> > > > >

From: _mallory
Date: Fri, Jul 03 2015 12:01PM
Subject: Re: Marking up file diffs in a table properly
← Previous message | Next message →

Normally in a diff you get + and - in front of the lines, as well as a
range of line numbers listing how many changes.

_mallory

On Fri, Jul 03, 2015 at 05:55:15PM +0200, Marco Zehe wrote:
> Hi Lynn,
>
> yes, something like "new", "changed" or "removed" could work as extra,
> maybe hidden, text for the line numbers I think. I'll wait a bit for other
> suggestions from the list, if any, and then put together something to see
> how that sounds as a suggestion. or maybe I'l use MozReview as a first
> entrance, and then we upstream it to Review Board once we see it working
> nicely within our custom install.
>
> Marco

From: deborah.kaplan
Date: Fri, Jul 03 2015 6:12PM
Subject: Re: Marking up file diffs in a table properly
← Previous message | No next message

Marco,

This isn't what you're asking, but one thing GitHub does is awesome for my use case (voice / keyboard, Firefox, Mouseless Browsing add-on): they add aria-label and role=button to the invisible span that gets the plus-sign on hover, to indicate you can click in that location to add a line note.

The attributes don't add keyboard accessibility -- I guess adding tabindex to every line in a lengthy diff would be terrible in its own way. But they do expose all the lines to Mouseless Browsing, which means I can leave line diffs without being able to mouse over them.

I tested in the review board tool adding aria-label and role=button to the TH elements, and it worked great.

(I have ideas about the semantic markup, but I feel like this is a good time to leave the thoughts to the daily screen reader users.)

Deborah Kaplan


On Fri, 3 Jul 2015, Marco Zehe wrote:

> Hi everyone, especially those of you who like to juggle data tables!
>
> I have a rather developer-centric issue I'd like to throw out for
> discussion there. This concerns how patches, or diffs, are being displayed
> in Github, and other tools. At Mozilla, we use a software called Review
> Board from https://www.reviewboard.org/. Those have in common that they
> display side by side diffs in a tabular fashion. The problem is that all of
> these implementations I've seen so far don't give enough semantic
> information to screen readers to give a really good experience. But before
> I approach Review Board with this, I would like to gather some input to see
> if we can better the situation at all, or if current table markup may not
> be sufficient.
>
> Here's a review request you can look at, by yours truly:
> https://reviewboard.mozilla.org/r/12135/ - This is the general review
> request.
> https://reviewboard.mozilla.org/r/12135/diff/2#index_header - This is the
> complete diff, the interesting stuff starts in the third data table on the
> page.
>
> The first few rows of the table contain the file name, and how many lines
> there are before the diff starts, with the option to show more context.
> Then, a few lines that are identical, and then, line 74 starts where the
> first difference occurs. As you can hear if you use this with a screen
> reader, the reading of column and row headers is not very nice.
> Specifically, the file name from the very top of the table, within the
> thead, is repeated over and over again.
>
> Second problem: The old and new files can only be distinguished by their
> column numbers (1 and 2 are old, 3 and 4 are new).
>
> And third, it is not immediately obvious if the line was changed, stuff was
> removed, added, or edited. The line numbers in both cases are marked as row
> header, which *seems* correct, but I would want some more semantics for the
> columns at least, and something more useful than just the file name
> repeated, at that.
>
> From your experience of working with accessible tables day to day, what
> would be the best solution here? Dissolve the single column header with its
> col span and put extra column headers with off-screen/collapsed text in it?
> Use different column headers for different sections and work with scope,
> axis or whatever attributes exist for these cases?
>
> I personally feel a bit overwhelmed with all the possibilities data tables
> have to offer, so I thought I'd call out to you ladies and gents for some
> ideas/advice/suggestions!
>
> Thanks!
>
> Marco
> > > > --