Accessible e-learning symposium

Jan/Sharron: Discussion of testing environments, APIP, if it is relevant to upcoming symposium

<shawn> Accessible E-Learning -- Online Symposium 16 December 2013 http://www.w3.org/WAI/RD/2013/e-learning/

<shawn> submission 15 November 2013

<shawn> APIP http://www.imsglobal.org/apip/

<shawn> Jutta Treviranus

<Zakim> shawn, you wanted to ask ETS

<shawn> QTI

to shawn: http://www.air.org/

<Jan> Measured Progress created a test environment called Nimble Tools

<Jan> In 2008, Minnesota got a grant with 8 other states and partnered with Measured Progress

<Jan> As a result, the Nimble Tools product essentially became the beginning of the APIP standard from IMS global.

<Andrew> IMS/APIP - http://www.imsglobal.org/apip/

<Jan> Part of APIP is actually under patent.

Shawn: The symposium will be in December, call for papers closed on Nov 15. It is a lightweight requirement. The "paper" can be scientific, position, quite flexible only needs to be 1000 words or so.
... seems like these testing requirements should be part of the symposium.

Jan: I could submit a paper to help people look at it a little bit differently.
... to consider and pay attention to other points of view around APIP and built in accomodations for testing

<Andrew> APIP FAQ - http://www.imsglobal.org/apip/apipfaqs.html

Jan: I submitted a paper to CSUN kind of an APIP 101 to just let people know what it is. Current documentation has errors and is quite dense. So I have been working on a more foundational document.

Shawn: If you are doing documentations and presentations on APIP people may think that you support it.

<Jan> http://www.imsglobal.org/apip/ - overview of APIP - the FAQ page is available from a link on this page.

Sharron: I will take an action to contact NFB to encourage them to submit papers to the e-learning symposium

Jan: I beleive in the notion of interoperability aspects of APIP but want to help people understand its limitations. Assessment environment is not the place to introduce new technologies. It must be introduced in the learning environment so kids know how to use them.
... people have different varying needs and a standard cannot take away the personal choices that students have in the classroom for the test environment.

Shawn: Everyone who submits a paper can participate but registration is limited and often fills up, so if you have colleagues who want to attend, they should pay attention and register early.

<Andrew> 9 December 2013: Registration opens

<shawn> how to get wai announcements http://www.w3.org/WAI/about/announcements.php

Action item check

<shawn> http://www.w3.org/WAI/EO/wiki/Action_Items

<shawn> eo-editors list <http://lists.w3.org/Archives/Public/wai-eo-editors/2013Oct/>

Shawn: Will keep the Done items listed for a while

Easy Checks - resize text

<shawn> latest draft: http://www.w3.org/WAI/EO/Drafts/eval/checks#resize

<shawn> comments: http://www.w3.org/WAI/EO/wiki/Easy_Checks#Resize_Text

Shawn: Thanks to Sharron, Sylvie and Denis for their comments on that. I addressed some and we have some that remain open for discussion. Let's go through those

Andrew: Reads Denis' comment - use text resize rather than zoom
... reads additional comments

Shawn: Everyone understand the point being made? the distinction between page zoom and text only zoom may not be clear enough. However, 2 of 3 browsers use the term "zoom text only"

Andrew: I am in favor of keeping the terminolgy used by the browsers so as not to add to the confusion

<Sharron> +1

<shawn> text-only zoom

<shawn> text-only zoom, and page zoom (which also zooms images, buttons, etc.)

Shawn: Now we say text-only zoom and page zoom to make the distinction up front. Should we revert to the exact term used by the browsers?
... no strong feelings?

Sharron: putting text-only and page *first* makes reading more understandable, makes distinction more clear

<shawn> +1

Andrew: No problem there, I think it is as clear as it needs to be.
... perhaps make three bullets rather than flowing text to show that we have 3 items we are trying to differentiate.

Shawn: I'll try it in the wiki
... on the page

Sharron: Yes, I like it!

Shawn: Yes it distinguishes each, makes it clear there is a difference....any concerns?

<Andrew> Web pages should be designed to remain readable and usable when users change text size

<Jan> perceivable and operable?

Shawn: Great words for those of us who know WCAG language...how is it for those who may not be as familiar?

<shawn> http://www.w3.org/WAI/EO/Drafts/eval/checks#resize

Shawn: with the changes we made (the bullets). The next paragraph begins with that notion...is this sentence even necessary anymore? Proposal is to delete...what does the group think?

<Andrew> +1 to delete "Web pages should be designed to work when users change text size."

Sharron: +1

<Jan> +1

<Anthony> 1

<Anthony> +1

Shawn: Looking at the issue of word wrapping, is the issue explained clearly enough, is there a way to make it more clear?

<Andrew> suggest "When text size is increased ..."

Sharron: It seems so clear and well-explained, but I don't know if it is because of my previous understanding.

Andrew: I am in the same situation, seems very clear to me. I submitted one suggestion above.

<Sharron> +1 to Andrew's suggestion to add "text-size"

Comment 1 VC on Zoom

<shawn> http://www.w3.org/WAI/EO/wiki/Easy_Checks_Comments#.5BOPEN.5D_Comment_1_VC

Shawn: It came in a while ago, we have simplified it considerably.
... added instructions for IE. is this a good resolution?

<Sharron> +1

<Andrew> +1

Shawn: any concerns?

All: none

Keyboard access, visual focus

<shawn> http://www.w3.org/WAI/EO/Drafts/eval/checks#interaction

<shawn> no comments http://www.w3.org/WAI/EO/wiki/Easy_Checks#Keyboard

Shawn: I will add an illustration for visible focus.
... a placeholder is now in the doc

Jan:Will the illustration show poor visual focus vs. good visual focus?

Shawn: We will leave it to the illustrator's discretion, and the focus group that determines how to approach

Anthony: Do we want to inlcude the idea of SHIFT+TAB to move backward through the interface?
... It is under the ToDo list to consider

<shawn> published version http://www.w3.org/WAI/eval/preliminary#interaction

<shawn> What to do:

<shawn> In a browser that supports keyboard navigation with the Tab key (for example, Firefox, IE, Chrome, and Safari; not Opera):

<shawn> Click in the address bar, then put your mouse aside and do not use it.

<shawn> Press the 'Tab' key to move through the elements on the page.

<Sharron> +1 to mentioning SHIFT+TAB

<Jan> +1 for shift-tab

<Sharron> +1

<Vicki> +1

<Andrew> suggest - "Press the 'Tab' key to move through the elements on the page; you can press 'shift-tab' to go backwards."

<hbj> +1 for Andrew

<Vicki> +1

<shawn> placeholder note at : http://www.w3.org/WAI/EO/Drafts/eval/checks#interaction

Shawn: Next is Alan's comment

<shawn> alan's comment: http://www.w3.org/WAI/EO/wiki/Easy_Checks#Keyboard

Andrew: reads the comment aloud

<shawn> this is the version : http://www.w3.org/WAI/eval/preliminary#interaction

Andrew: from Alan: visible and logical are not the same and may need more distinction. Another suggestion was to simply drop the sentence altogether.

<Andrew> suggest: "Keyboard focus should be visible and should follow a logical path through the page elements."

<Vicki> +1 for andrew

<Sharron> +1

<Jan> +1 for Andrew

<hbj> +1

Jan: Have we gotten across the point that it is *sufficiently* visible. Perhaps not in this sentence but somewhere in EasyChecks

Shawn: In most browsers the default focus is not especially easy to see. Are we telling web page authors to fix that? That they should improve the default focus indication?

<Andrew> very visible / highly visible / obvious ??

Jan: It is very important..it adds a cognitive burden to those who may have access issues already.

Shawn: However, we need to consider if that is a browser issue or a content issue?

Jan: I don't have the answer. But I can tell you that when I say "visible focus" most developers don't know what I am talking about.

Sharron: But increased focus is almost always provided on mouse hover

<Andrew> maybe we should make the point about duplicating the focus between mouse & keyboard

Shawn: But those *are* two separate issues.

<shawn> shawn points Jan to All functionality by keyboard: "Check that you can do everything with the keyboard; that is, you don't need the mouse to get to actions, options, visible changes, and other functionality. (A common problem is that some things are available only with mouse hover, and are not available with keyboard focus.)"

Helle: This is very true, very important. It is the conversation we had previously about the distinction between conformance and best practice.

Sharron: There was good conversation in a previous meeting where we traced down the requirement, based on SCs
... I will send the link to the minutes

<Jan> What is the success criteria for that?

<shawn> +1 to sharron remembering the discussions we had previously!

<Jan> +1 for Sharron sending the success criteria of mouse over = keyboard to list

Shawn: So Jan does that address your point?

Jan: Yes it is addressed

Shawn: So these changes need to be moved into the published draft
... anything else on Keyboard/visible focus?

Anthony: Are we mentioning specific technology and user needs by examples of form feilds etc?

Shawn: Is your question whether we are giving them enough to look for?

Anthony: Yes. In keyboard navigation, focus should be visible on active elements likes links, form fields, etc

<shawn> What to check for: Tab to all: Check that you can tab to all the elements, including links, form fields, buttons, and media player controls.

Shawn: Let's decide at the end of today's call if we are comfortable moving new language into published version.

<Vicki> +1

Andrew: It would help if the actions that you are meant to take were bolded to help skim the list.

<shawn> http://www.w3.org/WAI/EO/Drafts/eval/checks#interaction What to check for:

<Andrew> doesn't like extra space

<paulschantz> def easier to read

<Sharron> +1 bold, no space

<Jan> +1 on bold

<Jan> +1 on space

<hbj> agree with Andrew

<Andrew> +1 for bold / no space

<Anthony> +1 bold

<Sharron> +1 bold, can live with either space decision

<Vicki> +1 with spae

<Andrew> +1 no space :)

<Vicki> +1 bold and space

<paulschantz> +1 bold, I prefer space, but can live with both

<hbj> no spacing but can live with space

<Jan> +1 on the bold - now neutral on the space

<hbj> should this be a definition list and not bullet

<Jan> spacing really helps people with dyslexia too

<paulschantz> ?me what's normal? :-)

<paulschantz> YES, editor's discretion

Shawn: OK anything else for this section? OK, onward

Comment 2 on keyboard access

<shawn> http://www.w3.org/WAI/EO/wiki/Easy_Checks_Comments#.5BOPEN.5D_Comment_2_VC

<Vicki> +1

Shawn: Considering these comments, how would we word this so it makes sense to developers, Helle's group, etc

<Jan> I am not sure that "visible changes" will equal "visual focus" to developers

<Andrew> +1 to Jan (and refer to earlier too)

Sharron: (from the wiki) you don't need the mouse to activate or trigger (instead of get to)

<shawn> Check that you can do everything with the keyboard; that is, you don't need the mouse to activate actions, options, visible focus changes, and other functionality.

<Jan> +1 for activate

<shawn> Check that you can do everything with the keyboard; that is, you don't need the mouse to trigger actions, options, visible focus changes, and other functionality.

<Vicki> either trigger or activate, with a slight preference for trigger

<paulschantz> like showing the page title for those browsers that don't show it in the title bar

<Vicki> good point

Helle: activate is better also for second language English speakers

Shawn: Look at the sentence in complete context...it may be explained more clearly in another sentence
... there are more specific comments in visible focus section

<Andrew> http://www.w3.org/WAI/eval/preliminary#interaction has 2 bullets on 'visual focus'

<Anthony> +1 for trigger

<shawn> (A common problem is that some things are available only with mouse hover, and are not available with keyboard focus.)

Sharron: How about "A common problem is that events and information are dependent on mouse hover and are not made available by keyboard focus - and should be."

<Anthony> people might think tool tips also need to trigger at tab?

Andrew: need to add "some" before events

<Andrew> A common problem is that some events, including focus highlighting, and information are dependent on mouse hover and are not made available by keyboard focus - and should be

Shawn: What if we add examples

Jan: Yes that would help, especially if one of them is the highlighting that happens on mouse over
... any operation available by mouseover is avialable by keyboard, including highlighting text

<shawn> A common problem is that some [operation events and information visisble changes]are available only with mouse hover, and are not available with keyboard focus.

Anthony: people might think tool tips also need to trigger at tab?

<Andrew> and that's the problem with tool-tips when done with 'title' attribute

Shawn: If it is developer generated it is the same

Helle: What if they use title, which has become very popular

Shawn: whether or not tooltips show with mousehover is browser determined isn't it?

Andrew: And developers understand that and take advantage of that to make information available to mouse hover

Helle: Do screen readers not make a choice about whether titles are read or not?

Andrew: A title on a link chooses one or the other, you will not get both?

Sharron: Does it not depend on the settings?

Anthony: In default settings, if it reads the link, it does not read the title. If it reads the alt text, not the title.

Andrew: Under our current instructions, the lack of tool tip display may present as a problem to developers

Helle: I think it is important

Andrew: We add complexity in this discussion, is it necessary complexity? I am torn two ways. is it too complex for Easy Checks

Shawn: If you have a title, most browsers provide a tool tip pop=up
... one perspective is that if it popsup for mouse over it should also popup for keyboard access
... another is that the function is in the browser and it is not a developer responsibility

<Zakim> Andrew, you wanted to ask about UAAG

Helle: I don't think I have ever seen a tooltip that pops-up on keyboard focus

Shawn: If I program a change that occurs on mouseover, clearly I have a responsibility to provide that action on keyboard focus.
... but if the default treatment occurs in the browser however, that is an action for browser makers
... I would like to propose that in order to make all this a bit simpler we do the following:
... I could take most of the content from our internal draft

<shawn> http://www.w3.org/WAI/EO/Drafts/eval/checks

Shawn: Proposal is to take these changes and move them to our published draft

<shawn> http://www.w3.org/WAI/eval/preliminary

Shawn: The issue is that it will make our review simpler but are we comfortable enough with the current changes to do that?

<paulschantz> what are the main differences between the drafts?

Andrew: It is stable enough to move as long as another review is on the agenda for next week

Shawn: The internal draft has the newer text that we have been reviewing in the wiki and in meeting. Skim that to be sure you are OK with putting it in the public draft

Helle: I am OK with that but am unable to look further into it until next week so I will go with the majority.

Sharron: I favor the move

<paulschantz> I'm ok with it

Vicki: I am OK with it too

<Jan> Thanks, Shawn!

Shawn: Thanks all, we will keep going on this and review again next week.