See also: IRC log
<scribe> ScribeNick: ShaneM
None...
Liam - the work statement needs an edit. The sponsoring groups need to be APA and WebPlatforms now.
liam: that's done
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.
<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.
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
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 theoretical statements made in HTML and whether we were consistent, rather than looking for things that work. 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.
<liam> next meeting: 18th feb
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/ Succeeded: s/direction/theoretical statements made in HTML and whether we were consistent, rather than looking for things that work/ 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 diagnostic output]