See also: IRC log
trackbot, start meeting
Grr... still learning this stuff - command?
<oedipus> trackbot, please join
trackbot, start meeting
alternatives, including: longdesc:
zaxim, item 1
<scribe> scribe: jf
<oedipus> i/MK: moved my actions to 25th/scribenick: oedipus/
<oedipus> i/action-762?/scribenick: mattking/
As JF struggles with zakim commands, attendees round-robin introductions
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: http://lists.w3.org/Archives/Public/public-html/2011Mar/0697.html
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
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
longdesc, table summary, etc. may evolve, move to ARIA as a stronger mechanism
(JF +1 to Judy)
JB: use this group to clarify and get stronger consensus on these topics
<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 lifting
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> 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
... 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 requirements?
<oedipus> proposed requirements for verbose descriptor mechanisms: http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs
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 useful
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 replacement
(+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 issues
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 mechanism
... 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 discussion
<oedipus> proposed requirements for verbose descriptor mechanisms: http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs
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 @longdesc
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 determinable
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 action...
<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 accessing...
<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
<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 http://www.w3.org/2011/04/18-text-minutes.html#action01]
<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 points
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 http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs#Satisfying_These_Requirements_for_HTML5
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 requirment?
look at reqs, rather than implementation
useful to have a high-level reqs document
RS: being pragmatic - the need exists whether we use longdesc or other
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
... can RS scribe next week?
RS: can do in 2 weeks time
GJR: will scribe next week
<JF> bye all
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) FAILED: i/MK: moved my actions to 25th/scribenick: oedipus FAILED: i/action-762?/scribenick: mattking Succeeded: s/=1/+1/ Succeeded: s/Authoring and Best Practices documents/Authoring and Best Practices documents on how to design so that ARIA info is communicated to those not using an assistive technology/ Succeeded: s/I like that ARIA is mapping/JS: I like that ARIA is mapping/ Succeeded: s/programmatically determinable important to specify that there must be a means to separate the activation of the longdesc for exposure from the UA's universal link activation action/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.../ Succeeded: s/who/how/ Succeeded: i/JF: one thing important is to look at what has already started to happen/scribenick: oedipus Succeeded: i/RS: the thing I had the biggest issue with/scribenick: JF Succeeded: i/JF: on poster issue rejected/scribenick: oedipus Found Scribe: jf Inferring ScribeNick: JF Found ScribeNick: oedipus Found ScribeNick: JF Found ScribeNick: oedipus ScribeNicks: JF, oedipus Default Present: John_Foliot, Judy, mranon, Steve_Faulkner, Gregory_Rosmaita, Rich, Janina_Sajka, +44.203.239.aaaa, LynnH Present: Gregory_Rosmaita Janina_Sajka John_Foliot Judy LynnH Rich Steve_Faulkner mranon Regrets: Laura_Carlson Agenda: http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/0144.html Got date from IRC log name: 18 Apr 2011 Guessing minutes URL: http://www.w3.org/2011/04/18-text-minutes.html People with action items: add gregory status WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]