W3C home > Mailing lists > Public > public-html-a11y@w3.org > April 2011

[text] minutes: Text Alternatives Subgroup 2011-04-18 [draft]

From: Gregory J. Rosmaita <oedipus@hicom.net>
Date: Mon, 18 Apr 2011 18:16:02 +0100
To: public-html-a11y@w3.org
Message-Id: <20110418171438.M158@hicom.net>

thanks to John Foliot for scribing at the innaugural Text Alternatives 
Subgroup teleconference, minutes of which can be accessed as a 
hypertext document at:


as an IRC log at:


and as plain text following this announcement -- as usual, please
report any errors, clarifications, corrections, misatrributions 
and the like by replying-to this announcement on-list...

scribes for next 2 Text Alternatives telecons:
  * GJR
  * RichS

                             - DRAFT -

     Text Alternatives Subgroup of HTML Accessibility Task Force

18 Apr 2011


  See also: IRC log - http://www.w3.org/2011/04/18-text-irc


         Gregory_Rosmaita, Janina_Sajka, John_Foliot, Judy, LynnH,
         Rich, Steve_Faulkner, mranon





    * Topics
        1. Identify Scribe (list for PFWG generally:
        2. Organizing Our Work
    * Summary of Action Items

  trackbot, start meeting

  Grr... still learning this stuff - command?

  <oedipus> trackbot, please join

  trackbot, start meeting

  <oedipus> http://www.w3.org/2002/09/wbs/32212/201105_ftf/

  http://www.w3.org/WAI/PF/HTML/wiki/index.php?title=Scribe_List )

  alternatives, including: longdesc:
  http://lists.w3.org/Archives/Public/public-html/2010Aug/0112.html ;

  http://lists.w3.org/Archives/Public/public-html/2011Apr/0091.html ;


  confirm who/when

Identify Scribe (list for PFWG generally:
http://www.w3.org/WAI/PF/HTML/wiki/index.php?title=Scribe_List )

  <scribe> scribe: jf

  As JF struggles with zakim commands, attendees round-robin

  close agendum

Organizing Our Work

  JB: we may have others join the call today as scheduling permits
  ... review of goals of this sub-team

  concerns about longdesc, table summary, poster-alt

  we will look at each of these decisions and have discussions where
  useful, analyze , offer clarifications, etc.

  if that is not successful, then sub-group may look at FO, possibly
  coupled with expedited appeals to the director

  Judy can offer details and background on process options if required

  hopes that this is not the main focus of this group howeer

  JB: any further comments, questions or scope of this sub-group

  JS: nothing to add, this was a good summary

  <oedipus> JF: logged FO against chairs' poster decision

  MY FO for Poster-alt:


  name of group: text alternatives sub-group - any objections?

  JB: with no objections, that's the name of the group
  ... organization: between the 3 different items to date, there seems
  to be some similarities across the 3

  we have seen a lot of on-line discussion on these topics as well

  hope to identify any questions or differences of opinion, etc.

  hope that we can clarify and resolve quickly

  Judy may ask people on the calls to seek greater clarity. we may
  need to use some wiki space to manage this

  JB: who has read all 3 of these in detail

  <oedipus> GJR has

  SF: have read them, looking for the recurring similarities, don't
  actually see anything

  JB: items such as low usage, hidden data, etc.

  SF: these were countered as weak arguments

  JB: items such s uncontested arguments

  <oedipus> http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs

  SF: the chairs looked at various items, and rejected many items as
  weak arguments

  JB: low usage as a weak argument was a concern

  <oedipus> HTML 4.01 was subject to an intensive analysis for
  potential and known accessibility issues before it became a
  recommendation in December 1997. By the time activity on HTML5 was
  moved to the W3C, however, many such features had been stripped from
  HTML, many as "neglible use cases". Since then, however, previously
  deprecated accessibility features have begun to creep back into
  HTML5. This...

  <oedipus> ...change proposal, therefore, seeks to provide a safety
  net for known, implemented features, functions, and syntax which was
  specifically added to HTML 4.01 to increase accessibility, and for
  which there have not been any advances or improvements in HTML5.
  This is particularly important as HTML5 is being implemented
  piecemeal by developers, before a static specification is achieved

  <oedipus> ...therefore, HTML5 should retain those accessibility
  features of HTML in order to facillitate the ability of persons with
  disabilities to use sites and user agents that are incrementally
  phasing in support for HTML5 markup.


  low frequency argument is seen as damaging to accessibility

  reviewing the different rejections, one of the other issues was
  concerns about hidden meta-data

  link-rot, etc.

  longdesc, table summary, etc. may evolve, move to ARIA as a stronger

  (JF +1 to Judy)

  JB: use this group to clarify and get stronger consensus on these


  <oedipus> JF: 1 thing mentioned was moving some of these things into
  ARIA as new "home" for evolution of accessibility solutions -- want
  to express concern about that -- backwards move to push a11y on ARIA
  -- ARIA bridging tech until needed native semantics provided by ML
  devs; concerned moving in backwards directtion; ARIA is not the
  savior/only solution -- open to being convinced i am wrong, but...

  <oedipus> ...think that ARIA as it evolved was for dynamic web
  content (JS and widgets, roles, states and properties)


  I have a different opinion to John

  re: ghettoiazation and step backward

  these are very specific solutions to specific problems, prefer to
  see more generic solutions to these problems

  some say that it might be better to have an attibute that has
  greater reach - could be used with canvas etc.

  hving a more generic method makes it more extensibile

  RS: bridging technology argument was to appease the HTML WG

  honestly, to just sprinkle some semantics on something to make it
  accessible is a good thing

  adds declarations easily

  in native OS, this is very complicated

  with ARIA, set an attribute, and the browser does all the heavy

  now we can use ARIA to support SVG, and standard controls

  there remains a lot of work on the standard controls

  the problem I now have is that the HTML5 implementation for sthings
  like summary is inconsistant across browsers

  there are multiple things that authors need to do, and when we move
  to other languages it does it differently

  having a consistant way of doing this across many languages is a
  positive thing

  now that ARIA is part of the HTML5 spec, we have som win

  it was designed to be a cross-cutting solution for multiple languges

  <oedipus> what does aria-label mean for someone not using AT?

  positive to have have something across multiple OSes and browsers

  robust ARIA would even make WCAG2 easier

  JB: thanks for the input to date from JF, SF, RS

  would like to pull out some requirements

  <richardschwerdtfe> I just lost my phone

  <richardschwerdtfe> sorry

  <richardschwerdtfe> be right back

  GJR: appreciate the therory, but what is the impact on users not
  using AT?

  <Stevef> apologies I have to go

  (waiting for RS to re-join us)

  GJR: it is very appealing to have one common syntax

  but most of this is designed to work with a11y APIs, and there are a
  large portion of users not using AT that needs some of this

  we need to re-examine some of the basic assumptions of ARIA

  RS: does summary actually show up?
  ... works with AT.

  GJR: how does ARIA labeledby work for users who are not using AT?

  RS: if you have a table with @summary, what does a sighted user see?



  <Zakim> oedipus, you wanted to ask about ARIA for those not using AT

  wants to check something here. Is revisiting ARIA something that can
  be done without re-opening ARIA

  as advisory data - styling, etc.

  JB: one thing to note is that changing the way a11y is being
  designed due to appeasement is a bad way to design

  hope that this is not the main factor in revisiting

  <oedipus> GJR wanted to point out if move towards aria-based
  solution, will need a massive new addition to the ARIA Authoring and
  Best Practices documents on how to design so that ARIA info is
  communicated to those not using an assistive technology

  if better a11y is achieved by restoring these features, we should go
  that way

  however if a11y can be met better by using ARIA, then that is
  important info as well

  hears different points of view

  would be good to prove this in fact

  not eager to take a long detour, but curious to check to see how
  much agreement there might be]

  ie: cross UA support, etc.

  <judy> testing potential agreement on a simple set of requirements:

  J how easily could we get cross UA support of ARIA

  RS: we just positioned ARIA as a bridging technology - everything
  will be handled by the host language

  we did not intend that/d o that

  we didn't use ARIA to apease the WG

  JB: not a 'diss' on ARIA
  ... one of the things I am wondering is I hear people express
  different opinions and map against requirements

  hear concerns about cross UA support from GJR and JF

  <oedipus> any info conveyed to an a11y API via ARIA would also need
  to be conveyed in a device independent manner to non-AT users

  second item is that implementationn is important

  other item of concern is consistancy in implementation

  one requirement to not break backward compat

  there is a body of @longdesc content in existance already

  <oedipus> doesn't HTML5 have a mandate about backwards compatibility
  -- will check

  this may introduce conerns

  would it be useful to state some of this as shared views of

  <oedipus> proposed requirements for verbose descriptor mechanisms:

  JS: glad to see us talking about not breaking backward compat

  if we go around on these diff attributes, we can pretty much agree
  that there is something there that neads to be captured

  we need a programaticaly specific means to select the larger data,
  and not always be forced it

  <oedipus> strong plus 1 on ARIA-as-filtering device utility

  so if is all in the same kind of element (attribute) it may not be

  JS: I like that ARIA is mapping to APIs here, but we are also
  violating a fundemental principle by throwing out the old in favor
  of the new, when the new is unclear

  so when looking at items such as table summary, the weaker objection
  says use ARIA - fine but not yet implelemented

  seems short sighted to simply suggest that ARIA is ready for

  (+1 to Janina re: obsolencence)

  can we improve longdesc and summary? yes

  underlying principle is that we not discard historical attributes,
  relyability of our work

  keep the baseline we have already established - we have others that
  expect us to do so

  we are not yet there on understaning how ARIA can solve all these

  JB: will go through the queue

  <inserted> scribenick: oedipus

  JF: one thing important is to look at what has already started to
  happen -- concerned about @longdesc -- talked with many devs
  face2face -- discoverability issue is the "problem" -- not the
  ... poked chaals, and there is now plug-in for @longdesc for opera
  with a visual indication and a DI-independent way of exposition
  ... a11y features of HTML4 available for over a decade -- should
  honor that -- issue is that we have mechanisms in place, problem is
  doing something usefull for sighted users with a11y -specific markup
  ... takes a while for adaptation -- next major step is GUI based
  browsers need to do something useful with this stuff--already
  supported if UA supports HTML4
  ... moving techs into cross-ML support doc is good, but concerned
  about throwing out what is available and should reamain available

  <inserted> scribenick: JF

  RS: the thing I had the biggest issue with is that I agree that
  dumping @longdesc completely is a problem

  we need a deprecation strategy

  to give us a chance to get WCAG 2, EOWG to get ducks in order

  but cold-turkey dumping is busted

  JB: anybody disagree with rich's point? (none)

  example of something that hope to communicate in an organized way

  we worked hard to make these points

  can we capture that as a resoultion for this group?

  touching on the history of these features/attributes as part of our

  <oedipus> proposed requirements for verbose descriptor mechanisms:


  can we focus on link that GJR added re: requirements

  one question is: how much consensus has this page had in any of the
  TF meetings?

  GJR: this was a direct reaction to the chairs announcement to remove

  collect requirements in an agnostic manner

  purposefully written to not be bound to a specific solution

  JS: re- process. this was voted out by the PFWG as a recommendation

  JB: can we look at this for a few minutes

  <oedipus> requirement 1: A programmatic mechanism to reference a
  specific set of structured content, either internal or external to
  the document containing the described image.

  one of the things that stands out to me is undre progrmaitically

  seems to be leaving out the specific technologies


  the requirement for cross UA reqs does not stand out

  JB: are the other things that may be missing

  <oedipus> definition of programmatically determinable: A long
  description needs to be programmatically determinable. This relates
  to the information in web content. If technologies that are
  accessibility supported are used properly, then assistive
  technologies and user agents can access the information in the
  content (i.e., programmatically determine the information in the
  content) and present it to...

  <oedipus> ...the user. For instance longdesc as an attribute should
  be used as a hook by user agents and asssistive technologies in
  order to notify the user that a long description exists, so even if
  longdesc is applied to an image that also serves as a link, it is
  programmatically determinable to separate the activation of the
  longdesc for exposure from the UA's universal link activation

  <oedipus> ...(which is usually activated with the ENTER key, the
  SpaceBar, or by mouse click), so that the linked image retains the
  expected behavior in response to user interaction while a discrete
  mechanism is used to retrieve the long description. HTML4 puts it
  this way,"Since an IMG element may be within the content of an A
  element, the user agent's mechanism in the user interface for

  <oedipus> ...the 'longdesc' resource of the former must be different
  than the mechanism for accessing the href resource of the latter."

  JS: on the progrmatically determinable - if there is no means to do
  so, it is always there as text

  <richardschwerdtfe> ack

  <oedipus> GJR: programmatically determinable important to specify
  that there must be a means to separate the activation of the
  longdesc for an image functioning as a link without automatically
  causing link to be exposed using...

  JB: are people on the call familiar with this document

  is this the right group to be catching this doc in the TF?

  JS: likely yes. PF felt it could likely use some wordsmithing, but
  get it out for discussion

  soon rather than later

  <judy> ACTION: gregory add status to verbose descriptor requirements
  [recorded in

  <oedipus> ...UA's universal link activation action/

  JB: from the history, seems that mostly GJR and laura did the bulk
  of authoring


  the specific sets of requirements - there are 8 of them


  reviewing the 8 reqs seeking consensus

  GJR, one idea is to put up another document with these 8 as an
  ordered list, with more prose

  JB: checking around the call to see if there is consensus on these

  LH: still reading up on the background, not comfortable to comment

  MR: actually also contributed to the initial document that Laura
  started. Happy with this document however

  JB: looking at the standing requirements - could everyone take an
  action to revisit these 8 reqs and see if we can on next call
  address any lack of consensus?

  does this include not breaking forward/backward compat


  GJR: concern to not muddy the issue - this is mentioned in the how
  to satisfy

  JB: believes that not breaking backward compat is fundemental

  if the decisions of the WG were being reviewed, and if the review
  needed a basic set of reqs, shouldn't backward compat be there?

  JS: backward compat should be a higher level concept

  JB: if we were talking about new reqs (i.e alt-poster) then some
  cases there is substancial amount of legacy content

  <oedipus> advantages and disadvantages of solutions for verbose
  description requirements contained in detail in

  JS: the absence of a means to properly identify the image violates a
  fundemental req

  JB: can we look at the requirments section of the document with a
  fresh look in light of 3 rejected features

  any need for fine tuning?

  if so, can we stablize language by next call?

  Judy would also ask others not on this call as well

  RS: the question I have is: do we want to say "reinstate longdesc"
  or do we want to say we want a deprecation mechanism?

  JB: so for example, should not breaking backward compat be a

  look at reqs, rather than implementation

  useful to have a high-level reqs document

  for review

  RS: being pragmatic - the need exists whether we use longdesc or

  if they are going to remove it, industry needs time to adapt

  if we completely remove longdesc it is not attainable

  JB: this is something that we can discuss more

  may align with other practical feedback (weak objections, etc.)

  no clear evidence of evolving support

  RS: can cite gov legislation that if they remove something, we will
  have a mjaor problem

  JB: in preparing for next meeting - any objections to reviewing the
  requirements section - goal of consensus on tha section only

  <Zakim> oedipus, you wanted to suggest that subgroup email to
  public-html-a11y use the subject line [text] and to ask if it would
  it help to add requirement 8/9? backwards-compatibility: A

  GJR: when sending emails use [text]

  would it help to add another req for support of backward compat

  JB: surprised that it was not already there

  will be looking at the 3 rejection decisions, for patterns

  to understand how the chairs are informing on these issues

  ie: external, and the rejection of regulatory issues

  most of the other request for additional info seems complete


  <inserted> scribenick: oedipus

  JF: on poster issue rejected because not "spec-ready" text -- told
  them that was concentrating on need/requirement -- may need to
  tighten up language

  <JF> JB: next meeting - let's look at the requirements, and
  providing additional clarification

  JB: scribe volunteers for next few weeks?
  ... can RS scribe next week?

  RS: can do in 2 weeks time

  GJR: will scribe next week

  <JF> bye all

Summary of Action Items

  [NEW] ACTION: gregory add status to verbose descriptor requirements
  [recorded in

  [End of minutes]

Received on Monday, 18 April 2011 17:16:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:54 UTC