WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Marking up file diffs in a table properly

for

From: Marco Zehe
Date: Jul 3, 2015 7:54AM

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 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 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
> > > > > > > > > >
> > > > >