W3C

- DRAFT -

Web Content Accessibility Guidelines Working Group Teleconference

02 Sep 2014

See also: IRC log

Attendees

Present
Shadi, Bruce_Bailey, Kathy_Wahlbin, Joshue, David_MacDonald, Brent_Shiver, Mike_Elledge, bbailey, jon_avila, AWK, Kenny, alistair, Loretta, cstrobbe, Marc_Johlic, Michael_Cooper, James_Nurthen
Regrets
Chair
Joshue
Scribe
Kathy

Contents


<trackbot> Date: 02 September 2014

<Joshue> agedna+ Continue Institutional Memory Collection from 26th August 2014 - https://www.w3.org/2002/09/wbs/35422/IMCAugust2014/

<Joshue> Scribe list: https://www.w3.org/WAI/GL/wiki/Scribe_List

<Joshue> https://www.w3.org/WAI/GL/wiki/Scribe_List

<scribe> scribe: Kathy

September 2nd Survey - https://www.w3.org/2002/09/wbs/35422/Sept2nd_2014/

<bbailey> https://www.w3.org/2002/09/wbs/35422/Sept2nd_2014/results

Publication of editors draft

Josh - review of the commnents; jon had comment about h2

<AWK> http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140902/H2.html

<AWK> Text: Check that the a element contains an img element that has a null alt attribute, that is alt="", or text that supplements the link text and describes the image

Jon - text was confusing in the text for the tests

Jon - is the text that supplements the link text may be confusing

AWK - I think we did clarify it but the language may be mixed up

AWK - we should have the check that the image has null attribute or that the alt text is supplemental. Either one needs to be true

<David> +1

Josh - needs to be cleaned up

<Loretta> +1 David. Let's just fix it.

Jon - some text changes will clarify it

<AWK> Suggestion. remove #1 and keep 2 and change to: Check that the a element contains an img element that has either a null alt attribute value or a value that supplements the link text and describes the image

AWK - suggested text to clarify #1 and #2

Josh - any comments on the suggested text

David - suggestion for an update to the text

<David> Suggestion. remove #1 and keep 2 and change to: Check that the a element contains an img element that has either a null alt attribute value or a alt text value that supplements the link text and describes the image

Josh - any objections to the suggested text

AWK - need to have consistent terms

Jon - fine with either term

Josh - prefers Andrew's version

David - no strong preference

+1

<jon_avila> +1

<Mike_Elledge> +1

<David> +1

<Loretta> +1

<agarrison> Andrews +1

<bbailey> +1 to AWK edit

<Joshue> +1

Josh - any other comments?

Josh - we will use Andrew's suggested text

<Joshue> http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140902/H2.html

RESOLUTION: publish as amended. Andrew's updated text will be used for H2.

Josh - the change will be integrated in the coming days

RESOLTION: the editor's draft will be published

<Loretta> :-)

<Mike_Elledge> :^)

<bbailey> :)

Josh: both shadi and Alistair have items for the agenda

<AWK> XML documents updated so ready for publication (including diff markup, Michael)

<Joshue> https://www.w3.org/WAI/GL/wiki/Creating_a_conforming_alternate_version_for_a_web_page_designed_with_progressive_enhancement

<bbailey> https://www.w3.org/2002/09/wbs/35422/Sept2nd_2014/results

Final review draft of the technique

"Creating a conforming alternate version for a web page designed with progressive enhancement"

<agarrison> http://www.edgeatlanta.com/news/national

Alistair - looking for an example

Alistair - example provides different view for low bandwidth

Alistair - this would be the conforming version

AWK - Live example is not necessary for approving it but it would be good to have it. Have one that is simple and easy to use.

Alistair - can put together an example

Josh- any objections to accepting this

David - this is the dumbed down HTML version that provides sites from providing alternative version without having to fix the other one

RESOLUTIONL: accepted

Josh - please put in some live examples that can be included

AWK - we had a discussion on captioning, the check says to check for a conforming version - this is an example of where we have done this

<Joshue> https://www.w3.org/2006/02/lc-comments-tracker/35422/NOTE-WCAG20-TECHS-20140306/2963

Response to comment 2963: F89 confusing

Josh - any objecting to accepting the response?

RESOLUTION: accepted

Update on Accessibility Support Database Update from Shadi

<shadi> http://www.w3.org/WAI/accessibility-support/dev/

<Joshue> B-)

<shadi> http://www.w3.org/WAI/accessibility-support/dev/

Shadi - this is an update on the work done on the accessibility support database

Shadi - this has the latest updates

Shadi - we have been working on the workflow

Shadi - when the test cases are ready, they can be uploaded

Shadi - everyone has access as contributor role

Shadi - you have the power to delete test cases so be careful

Shadi - when you get to the page, you can browse and run test cases. You can also submit test case using your W3C account

Shadi - can see published WCAG techniques and editor draft techniques

Shadi - there are two labels: unconfirmed and accepted

Shadi - can add code and files to the test case

Shadi - form has not yet been approved

Shadi - when you go back to the homepage, browse test results

Shadi - can filter to show unconfirmed test cases

Shadi - that is the main change. Still creating functions to add/delete to maintain the database

AWK - where is the unconfirmed test case

Shadi - all of them are unconfirmed

Shadi - are making changes to make it easier

James - I see version numbers but not point releases for the AT

Shadi - we are storing the different versions, so we can roll back results

James - the exact version is important to know if it is supported

Shadi - the versions are dynamic from the database so if the information is provided it will be included

Shadi - can look at this in the environment and people can enter in it

<AWK> I do see Windows 6.1 in the OS list

James - not requiring people to enter in point release values

Shadi - This is automatically being filled in based on what the browser is sending over

James - browsers are sending more information

Shadi - then this is a bug

Shadi - the challenge is the granualarity

Shadi - we are thinking about this

Alistair - the versions need to be stored when the test is done

Alistair - the test cases look manual, are any automated

Alistair - who and when do you envision users to use the tool?

Shadi - test cases are not easily automated; volunteers are needed

Alistair - concentrate on the ones that need to be manually checked

Shadi - this was designed for test cases for manual review

Shadi - this is an attempt to do it using crowd sourcing

Shadi - this could come from the working group as techniques are developed

Shadi - test cases can be entered directly into the tool. This may also encourage people to review

David - found a couple of bugs

Shadi - there is the GitHub list

Shadi - does not include G techniques

David - there are HTML techniques in G

<jamesn> q to ask if you want comments on the accessibility of the system?

Josh - visual look and feel; structure looks good but the color contrast is poor

Shadi - we are happy to take suggestions

Josh - some simple changes could make a difference

Shadi - can log this into GitHub

https://github.com/w3c/wai-axsdb-web

https://github.com/w3c/wai-axsdb-web/issues

James - what is the framework used?

Shadi - some user testing has been done

Shadi - let us know about issues

James - the logout button should be a button not a link

James - if it looks like a button visually then it shoud be a button

Shadi - will look into this

Alistair - failure conditions

Shadi - we did not pull them in since the usage would be limited

Shadi - is there a failure that needs a test case

Shadi - this is primarily for techniques

<Joshue> KW: Is mobile included?

Shadi - this will work for mobile

<Joshue> KW: THe Mobile TF is writing techniques and testing, so we could use this right?

<Joshue> SAZ: Yes, that is my hope. Its buggy but workable

<Joshue> SAZ: The WG should start testing

<Joshue> SAZ: As you develop techs, the test cases could be written directly with this tool

<Joshue> SAZ: This will also give the public the chance to contribute.

<Joshue> KW: The Icon fonts need aria-hidden

<Joshue> SAZ: Ok

<shadi> http://www.w3.org/WAI/accessibility-support/dev/#/results-technique.html/H4

<Joshue> SAZ: Overview of approaches to linking to techs etc

<Joshue> <discusses design features>

Josh - would you like us to review; where can we help

<jamesn> q to note that the fonts are (I think) in the private use area of unicode so shouldn't need aria-hidden

Shadi - the big question is: Is this tool useful?

Shadi - can be added to the accessibility support area of the techniques

Shadi - we can check in a few weeks

Josh - the more information about the system is null link

Shadi - there will be more information and guides

Josh - when will this be up and running

Shadi - 2-3 weeks

James - the fonts may not need aria-hidden

<agarrison> Back button doesn't seem to work on http://www.w3.org/WAI/accessibility-support/dev/#/log-in.html

<Zakim> AWK, you wanted to ask what the situation is regarding future development - resources available?

AWK - future development: what resources are available

Shadi - essentially none

Shadi - bugs will be fixed

Shadi - major features will not be added at this time

AWK - this helps to manage our expectation

Josh - good job, thanks for the update

Shadi - look forward to feedback

Shadi - names are logged in the test cases

Institutional Memory Collection for 26th August 2014

<Joshue> https://www.w3.org/2002/09/wbs/35422/IMCAugust2014/results

Institutional Memory

Josh - always good to talk through these

<Loretta> I thought we were supposed to edit the wiki itself.

Josh - AWK added information to the WIKI

Loretta - I did too

Loretta - the last paragraph was what I added

Josh - debate orginally about what was sufficient for this

https://www.w3.org/WAI/GL/wiki/WCAG20/Institutional_Memory/SC_2.4.1

<Joshue> https://www.w3.org/WAI/GL/wiki/WCAG20/Institutional_Memory/SC_2.4.1

<David> https://www.w3.org/WAI/GL/wiki/Main_Page

David - is there a link on the main page to this

Josh - no

<Joshue> lol

AWK - always some amount of debate about the number of links

<David> I added link to main page https://www.w3.org/WAI/GL/wiki/Main_Page

AWK - there is a perception that this is only for screen readers users since the keyboard support is not default in the browsers

<jon_avila> Some people question whether this is relevant to mobile touchscreen devices.

AWK - gets into the WCAG / UUAG

Loretta - a lot discussion about efficient keyboard support / navigation

Josh - now there are other things that we can use to meet this

Loretta - there is usability issues for keyboard users that we did not fit into the technique

Josh - maybe something for later

<jon_avila> There is also applicability for software -- e.g. equivalent to moving between panes of software applications.

Bruce - remembers that this being added from 508 .22(o)

Josh - is there other information that should be added to the WIKI

Josh - look at the second one on page titles

<Joshue> https://www.w3.org/WAI/GL/wiki/WCAG20/Institutional_Memory/SC_2.4.2

<jon_avila> I asked it.

AWK: jon responded to question on the list about iframes, which made me remember this
... iframe is embedded into the page, this does not apply
... the question was about iframe embedded into the page, what do you do for title

<jon_avila> I found that JAWS 15 and IE will announce the embedded page title over the title attribute on an iFrame if one is present.

<David> +1

AWK: frame does need a title - covered under other success criteria

<jon_avila> could you meet 2.4.2 with an embedded HTML page title if it was accessibility supported and no iframe title.?

Loretta - oriented around navigation orientation issue

Loretta - also added for cognitive impairements

Josh - reading Loretta's comment - page titles do not need to be unique

Bruce - contemporary browser behavior makes this requirement less relevant; harder see the page title

Bruce - this is more difficult requirement for other types of formats

<jon_avila> This topic raises questions around mobile app titles where space is limited and hybrid or native apps may not show titles. Applying WCAG to non-web ICT indicates page titles are equivalent to app titles.

Josh - this is the first thing screen reader reads

AWK - trend is to show smaller pieces of the title

<Zakim> AWK, you wanted to ask bruce what formats doc title is hard for

<Joshue> KW: Mobile also has shorter titles

Bruce - filename gets confused with document title

<jon_avila> In Safari on iOS I see iOS displaying the url and not displaying the page title.

Jon - on iPhone Safari shows the URL and there is no page title

James - can see the page title in the tab view

Jon - both have consequences to mobile apps

Jon- do all mobile app pages need a title

Josh - out of time

<Mike_Elledge> bye!

<AWK> trackbot, end meeting

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-09-02 16:33:06 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/includeded/included/
Found Scribe: Kathy
Inferring ScribeNick: Kathy
Default Present: Shadi, Bruce_Bailey, Kathy_Wahlbin, Joshue, David_MacDonald, Brent_Shiver, Mike_Elledge, bbailey, jon_avila, AWK, Kenny, alistair, Loretta, cstrobbe, Marc_Johlic, Michael_Cooper, James_Nurthen
Present: Shadi Bruce_Bailey Kathy_Wahlbin Joshue David_MacDonald Brent_Shiver Mike_Elledge bbailey jon_avila AWK Kenny alistair Loretta cstrobbe Marc_Johlic Michael_Cooper James_Nurthen
Found Date: 02 Sep 2014
Guessing minutes URL: http://www.w3.org/2014/09/02-wai-wcag-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]