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 9:55AM

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