Minutes from the 4 February 2016 HTML A11Y Task Force Call

Folks,

The draft minutes from the call are at
https://www.w3.org/2016/02/04-html-a11y-minutes.html

A text version is below:

[image: W3C] <http://www.w3.org/>
- DRAFT -HTML Accessibility Task Force Teleconference04 Feb 2016

See also: IRC log <http://www.w3.org/2016/02/04-html-a11y-irc>
Attendees
PresentIanPouncey, LiamQuin, JS, Cynthia, ShaneM, MarkS, Judy, chaalsRegrets
ChairSV_MEETING_CHAIRScribeShaneM
Contents

   - Topics <https://www.w3.org/2016/02/04-html-a11y-minutes.html#agenda>
      1. Changes to the agenda
      <https://www.w3.org/2016/02/04-html-a11y-minutes.html#item01>
      2. Housekeeping items
      <https://www.w3.org/2016/02/04-html-a11y-minutes.html#item02>
      3. alt (text alternatives)
      <https://www.w3.org/2016/02/04-html-a11y-minutes.html#item03>
      4. Footnotes
      <https://www.w3.org/2016/02/04-html-a11y-minutes.html#item04>
      5. Transcripts
      <https://www.w3.org/2016/02/04-html-a11y-minutes.html#item05>
      6. AccessKey
      <https://www.w3.org/2016/02/04-html-a11y-minutes.html#item06>
   - Summary of Action Items
   <https://www.w3.org/2016/02/04-html-a11y-minutes.html#ActionSummary>
   - Summary of Resolutions
   <https://www.w3.org/2016/02/04-html-a11y-minutes.html#ResolutionSummary>

------------------------------

<scribe> ScribeNick: ShaneM
Changes to the agenda

None...
Housekeeping items

Liam - the work statement needs an edit. The sponsoring groups need to be
APA and WebPlatforms now.

liam: that's done
alt (text alternatives)

janina: we are waiting for ARIA to finish defining how we will handle
extended descriptions.
... that should be done by the next aria heartbeat.
... There is interest in DPub, and probably here, that we circle back and
provide guidance on how long an alt text should be.
... how big is too big. If we are using figcaption instead of an alt can we
algorithmically figure out if it is too long to be useful.
... DPub wants to know how to give guidance on when to switch over from alt
to longdesc / detailedsummary.
... we got some pushback on specifying length back in the day. Is there
some way to say it without seeming too strict and/or too arbitrary.

Cyns: Might be able to get it added to a usability session, but I would
need some help.

<Zakim> Judy, you wanted to comment on heuristic aspect

Judy: It would be useful to separate out some of the questions. It would be
useful to do some usability testing.
... Janina has raised the possibility that some length of "alt" where the
usability factor starts sharply declining. Determine that and help guide
authors.
... there was some anecdotal evidence before. But some real data would be
useful.
... Janina also mentioned the heuristic question - depending on where the
alt appears is there a way to guide authors to use a caption instead.
... We did some research on this and determined that extended figure
captions were not usually a good alternative to the alt text.
... there were examples where the figure captions were more about the
scientific methods (for example).

<chaals> [chaals joins]

Judy: Another is looking display things. Examine browsers and see what is
done with very long alt text.

janina: Liam had done some testing on this and found that the behavior was
not always ideal.
... there was sometimes truncation of what the alt was.

ShaneM: Note that there is text about this in
https://w3c.github.io/alt-techniques/#alt-restrict-overflow

liam: There was some truncation. Things can be done with CSS to mitigate
the problems.

Cyns: There was a setting in IE that toggled the setting. It is not in Edge
now. Is it really an issue still?

liam: It can be an issue if there is some block that prevents an image
displaying (firewall, unsupported format)

chaals: The A11Y issue is where the image is unclear and you need the text
to determine what it is really about. It is too low contrast for example.

liam: The HTML spec forbids displaying the alt text in the same way as
title text. So some content management systems duplicate the alt text in
the title so it can get displayed.
... it should be clarified in the default browser style sheet so we know
what happens when alt is too long.

janina: it is not just screen readers that will have a11y concerns.

Cyns: This might be a good use for extensions. An extension that
automatically displays the alt text when selected.
... (a browser extension)

<chaals> [There have been various extensions written for things like this.
It's a good use case for showing how to fix the browser bugs]

Judy: It seems like an extension is just another hurdle.

Cyns: Some browser vendors feel that settings are bad. Extensions are a lot
faster to get developed than getting a setting added to a browser.

Judy: But from a11y perspective it shouldn't be required to get an
extension.

Cyns: Extensions are just another type of AT.

liam: an example might be an image for a symbol. and there is alt text to
describe the alt text. There isn't room to show the alt text in the space
for the letter. If the browser put the full text there then the display
would be garbled in the event of a mathematical equation.

Cyns: That's why we had a setting in IE. But we had 1000 settings, and
users didn't like that.

liam: and occasional users won't know that there is a setting.

Cyns: Yes.

janina: I will find pointers to the previous discussion we had about this.
Liam please update us on the research you did and Cyns please do that
usability testing.

Cyns: Could you drop me an email with a couple of sentences on what we are
really looking for?

Judy: I would like to be copied on that. I think we want to ensure the
questions are asked clearly and separately instead of conflating them.
Footnotes

<liam> ShaneM: footnotes

<liam> ShaneM: we did some requirements gathering and I put together a wiki
page

https://www.w3.org/WAI/PF/HTML/wiki/Notes

<liam> We have to ask, what kind of problem are we trying to solve. The
problems are not unique to accessibility.

<liam> epub/dupb agree.

<liam> There's a connection between items in a document and this has to be
made manifest in ways that are conducive to the flow of the document.

<liam> E.g. a region in the bottom of the screen, and references from the
page showed up if they were visible

<liam> no consistent way to mark this up

<liam> "Given a good front end, the creation of annotations should be as
easy, dedicated, elegant and accessible as any office product." - Robert
Sanderson

<liam> I did go to dpub meeting this morning; no changes... there's roles
defined in doc-aria for footnotes, footnote, and noteref

<liam> but noteref mechanism is up in the air

<liam> I don't mind using role but doesn' solve the general problem

<liam> an HTML extension spec is the obvious thing to do

<liam> I think there's interest but I'm not sure there's energy

<liam> Liam: there are probably also CSS requirements

ShaneM: some things can be done already with CSS. Some things would require
scripting.

liam: there might be enough enthusiasm in the css community for this.

<liam> JF: not sure about lack of energy. I know when I was at a bank this
was a huge issue

<liam> e.g. multiple refs to the same footnote, "back to text" gets really
hard

JF: this is a huge issue at the bank when I worked there. Multiple links to
the same note and navigating back and forth is hard.

<liam> so could use some support from browsers

<liam> ShaneM: Web Components can do pretty much anything you want; in an
extension spec I'd probably do it that way as a polyfill as a proof of
concept

<liam> e.g. if a user put focus on an item that had a note reference it
pops up and escape takes you back

<liam> JF: Liam mentioned publishing where they're still working on [print]
rules and need to support that

<liam> but there's a need for a semantic structure

<chaals> [ `*[rel~=footnote] { /* link style */ } *[role=footnote] { /*
footnote style */ } … ]

<liam> JS: Charles, if we come up with a proposal is it likely to get
implemented in browsers?

<liam> Charles: this is determined by talking to browser people

<liam> [Charles mentions the Back button]

<liam> Charles: if it's a typed link, I can see some possibility of browser
special treatment. But if it isn't based pretty heavily on a link I doubt
and browser team would really be interested..

<liam> ShaneM: not getting an actional spec from dpub; it'll be us

<liam> JS: are there enough requirements?

<liam> ShaneM: yes

<liam> I was planning to work with David McDonald on this

<Zakim> ShaneM, you wanted to discuss whether this is really a link

<liam> ShaneM: Charles mentioned link behaviour, and that's a ay to support
some of this

<liam> I'm not sure that's the semantic, has ot be the semantic, it's a way
to implement a fn

<liam> It doesn't have to be navigable to me

<Zakim> liam, you wanted to distinguish fn and endnote

<liam> Liam: user should not have to actuate anything for a footnote; an
endnote is different.

<liam> Charles: disagrees - can point people down to the bottom of the page
(a small amount of work but a distraction)

<liam> The Web isn't the same as a piece of paper, you can have popup
information, can have [expanding in-place] (details/summary)

<liam> References, endnotes, footnotes, the different tricks publishers use
to make it easier, parentheses are another, tricks that fork people's
attention.

<liam> We don't have exactly the same bag of tricks as publishers on the
Web, can assign particular type information e.g. detail with a role that's
recognised

<liam> and can be given special treatment

<liam> links, glossary, etc are other examples

<liam> Trying to replicate the paper experience is stupid

<liam> We shold not be bound by the limitations of paper

<Zakim> ShaneM, you wanted to point out that whether it is stupid or not,
there are requirements

<liam> ShaneM: I don't disagree about dead trees on a screen, but there's a
community here, people and money behind them

<JF> +1 to Shane

<liam> This isn't Bob in a garage somewhere, it's people like Wiley, it's
te academic community, that's why we're here, we can't discount them just
because we thing it's stupid

<liam> JB: +1 to ShaneM that Liam and Charles are both right

<liam> I didn't hear Liam saying we can't exclude the new ways but rather
to be midful of some of the ways that publishing conventions have tried to
address over the years

<chaals> [I'm certainly not discounting the requirements, I am pointing out
that there are limitations to what we can do in our medium by which we are
bound, there are limitations in paper by which we are not, and we need to
figure out what is a sensible way to translate interactions from one
paradigm to another]

<liam> Charles gave a great overview of digital ways, too.

<Zakim> janina, you wanted to suggest that we need notes to be objects, not
just offsets

<liam> JS: I also think both Charles and Liam are correct. We're not giving
digital publishing enough to work with and become creative in going beyong
their traditional ways

<liam> Yes, they developed a lot of clever ways to deal with things in the
page.

<liam> Now we have new opportunities, although they still need to support
the old in the meantime.

<liam> We're primarily giving them, the note starts here, and not an entire
object with a span - I hope that's in the requirements

<liam> e.g. if footnotes are grouped or go from one to anohter and interact
with back button

<liam> Doesn't sound like anyone is against moving forward, so need a
proposals

<liam> OWP are the guys that will have to implement

<liam> ShaneM: I'm inclined to propose use cases and semantic markup, now
let's talk about behaviours

<liam> JS: OK

<liam> we have consensus there. Thank you.
Transcripts

JF: There is a new task force about a cloud browser.

janina: Talk about that at the top of APA. Send an email around about it
AccessKey

chaals: I put the pieces that are around into the web platform working
group.

That group is making an HTML spec that reflects what works.

The WICG is the place to go with what ought to work but doesn't yet. It
cant be in the base spec until it actually works.

Of the access key stuff, some is for the future because it is not yet
implemented. Other bits are being changed as the implementations change.

As to panels, there is some work being done with polyfills and
socialization.

scribe: that is the obvious approach with transcript as well.

janina: last time around there was some contention about transcript. Is it
still there?

chaals: depends on what you mean. There were debates about direction.
People seem to have relaxed about that.

janina: there was a lot of technique debate before. It was all over the
place.

JF: the last time we talked about this inseattle, but the conclusion was
there was a need but no progress.

janina: were the people who disagreed at the meeting?

JF: no. MS, Google, and Mozilla were in the room. Apple was not.
Summary of Action ItemsSummary of Resolutions[End of minutes]
------------------------------
Minutes formatted by David Booth's scribe.perl
<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> version
1.144 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2016/02/04 16:59:31 $
------------------------------
Scribe.perl diagnostic output[Delete this section before finalizing the
minutes.]

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/ idea/ ideal/
Succeeded: s/link/typed link/
Succeeded: s/treatment/treatment. But if it isn't based pretty heavily
on a link I doubt and browser team would really be interested./
Succeeded: s/proposal/a proposal/
Found ScribeNick: ShaneM
Inferring Scribes: ShaneM
Present: IanPouncey LiamQuin JS Cynthia ShaneM MarkS Judy chaals

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 04 Feb 2016
Guessing minutes URL: http://www.w3.org/2016/02/04-html-a11y-minutes.html
People with action items:


[End of scribe.perl
<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> diagnostic
output]

-- 
Shane McCarron
Managing Director, Applied Testing and Technology, Inc.