Re: Minutes from the 4 February 2016 HTML A11Y Task Force Call

Hi Folks

Sorry I haven't been around. My focus has been on the WCAG Mobile task
force extension which meets at same time, and they've needed me to help
with with Success Criteria formulation and requirements gathering which is
an area I can contribute considerably.

I read the minutes. I'd like to get involved with Footnote, and help to
write the spec... I really like the idea of not being limited to jumping
the user to and from the footnote where the reference information sits at
the bottom of the page or end of document, but rather just opening as a
show/hide or mini lightbox, which returns user with escape key. I think
that might be a successful one approach to overcome the issue of many
references and one footnote, and not knowing where to return the user once
they get on the footnote. I will update my article to provide this as a
possible solution to this issue, which seems to be a blocker to progress
whenever footnote gets momentum.


Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*
Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Thu, Feb 4, 2016 at 12:03 PM, Shane McCarron <shane@aptest.com> wrote:

> 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, chaals
> RegretsChairSV_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.
>