- From: Christophe Strobbe <strobbe@hdm-stuttgart.de>
- Date: Thu, 4 Aug 2016 15:12:10 +0200
- To: w3c-wai-ig@w3.org
- Message-ID: <bb74e2a0-9187-bb97-df80-6888ff0fe9fb@hdm-stuttgart.de>
On 4/08/2016 12:37, Olaf Drümmer wrote: > Wouldn’t one want to be using UTF-8 all the time anyway? Yet, that's what I do, but some web content authors don't use the right configurations for their tools. Possibly, some authors publish their content on a server where they can't change the HTTP charset parameter for UTF-8. Best regards, Christophe > > Olaf > > >> On 04.08.2016, at 11:50, Christophe Strobbe <strobbe@hdm-stuttgart.de >> <mailto:strobbe@hdm-stuttgart.de>> wrote: >> >> >> On 25/07/2016 17:16, Cohn, Jonathan wrote: >>> VoiceOver also has no issues with multibyte. One does have to make >>> sure the lang attribute is set correctly in the HTML. >> >> Setting the lang attribute correctly is good advice, but is it >> sufficient? >> One issue that I encounter rather frequently is that pages that use >> multi-byte content are still sent over the network as Windows-1252 or >> a variant of ISO/IEC 8859. On the user side, this can usually be >> fixed by choosing a different encoding in the browser (e.g. "More >> tools ..." > "Encoding" in Chrome's hamburger menu), but most >> non-technical users don't know about this feature. In some cases, >> even changing to a different encoding won't help. I assume this is >> because both the document encoding and the server's HTTP charset >> parameter are incorrect. >> (See <https://www.w3.org/International/articles/http-charset/index>.) >> >> Best regards, >> >> Christophe >> >>> >>> Over the weekend, I read an article from a Korean company where >>> even though the specific page was in English, VoiceOver (on IOS) >>> started reading it in Korean. >>> >>> >>> *From:* Sean Murphy (seanmmur) [mailto:seanmmur@cisco.com] >>> *Sent:* Monday, July 25, 2016 2:23 AM >>> *To:* Tanaka, Satoko <sako-t@jp.fujitsu.com>; Bryan >>> Garaventa <bryan.garaventa@ssbbartgroup.com>; Jonathan >>> Avila<jon.avila@ssbbartgroup.com>; WAI IG <w3c-wai-ig@w3.org> >>> *Subject:* RE: Question: Key Operation of Dropdown menu >>> >>> What specific questions do you have in relation to screen reader >>> support with multi-byte language screen reader’s? As I know Jaws for >>> Windows does support Japanese and believe other Asian languages as >>> well. I suspect Voice-Over also does and haven’t looked into it. >>> >>> Sean Murphy >>> >>> *From:* Tanaka, Satoko [mailto:sako-t@jp.fujitsu.com] >>> *Sent:* Friday, 22 July 2016 5:29 PM >>> *To:* Bryan Garaventa <bryan.garaventa@ssbbartgroup.com >>> <mailto:bryan.garaventa@ssbbartgroup.com>>; Jonathan Avila >>> <jon.avila@ssbbartgroup.com <mailto:jon.avila@ssbbartgroup.com>>; >>> WAI IG <w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org>> >>> *Subject:* RE: Question: Key Operation of Dropdown menu >>> >>> That’s great. Thank you for the explanation, Bryan. Much appreciated! >>> If someone knows about screen reader’s behaviors on >>> multi-byte-language environments, any comments and advices would be >>> appreciated. J Thank you! >>> >>> Many thanks and kind regards, >>> Satoko >>> >>> *From:* Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com] >>> *Sent:* Friday, July 22, 2016 4:11 PM >>> *To:* Tanaka, Satoko/田中 智子; Jonathan Avila; WAI IG >>> *Subject:* RE: Question: Key Operation of Dropdown menu >>> >>> When I wrote these articles I was using the English versions of >>> these programs, however the underlying functionality would be the >>> same regardless. For example, the way that VoiceOver works by touch >>> is the same in English as it is when using any other language that >>> iOS supports, as well as for JAWS and all of the languages that it >>> supports on Windows, and so on. >>> >>> There might be some differences in some languages that use right to >>> left language displays, but the input and output of the base >>> platforms should remain consistent. Others here may be able to >>> elaborate more on how this works in the background for Japanese and >>> Chinese language interaction models though. >>> >>> All the best, >>> Bryan >>> >>> >>> Bryan Garaventa >>> Accessibility Fellow >>> SSB BART Group, Inc. >>> bryan.garaventa@ssbbartgroup.com >>> <mailto:bryan.garaventa@ssbbartgroup.com> >>> 415.624.2709 (o) >>> www.SSBBartGroup.com <http://www.ssbbartgroup.com/> >>> >>> *From:* Tanaka, Satoko [mailto:sako-t@jp.fujitsu.com] >>> *Sent:* Thursday, July 21, 2016 11:03 PM >>> *To:* Bryan Garaventa <bryan.garaventa@ssbbartgroup.com >>> <mailto:bryan.garaventa@ssbbartgroup.com>>; Jonathan Avila >>> <jon.avila@ssbbartgroup.com <mailto:jon.avila@ssbbartgroup.com>>; >>> WAI IG <w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org>> >>> *Subject:* RE: Question: Key Operation of Dropdown menu >>> >>> Hi Bryan, >>> >>> Thank you so much for the information. It is actually helpful. >>> Are these articles about English version of screen readers? I mean, >>> do you know whether there are any differences in their behaviors >>> between English environment and other environment, such as Japanese >>> and Chines? >>> >>> Many thanks and kind regards, >>> Satoko >>> >>> *From:* Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com] >>> *Sent:* Friday, July 22, 2016 1:30 PM >>> *To:* Tanaka, Satoko/田中 智子; Jonathan Avila; WAI IG >>> *Subject:* RE: Question: Key Operation of Dropdown menu >>> >>> Hi Satoko, >>> It may be helpful to read the screen reader sections at >>> http://whatsock.com/training/#hd32 >>> >>> This covers how JAWS and NVDA work on desktops plus VoiceOver on iOS >>> and how these screen readers differ with regard to interaction and >>> accessibility. >>> >>> All the best, >>> Bryan >>> >>> >>> Bryan Garaventa >>> Accessibility Fellow >>> SSB BART Group, Inc. >>> bryan.garaventa@ssbbartgroup.com >>> <mailto:bryan.garaventa@ssbbartgroup.com> >>> 415.624.2709 (o) >>> www.SSBBartGroup.com <http://www.ssbbartgroup.com/> >>> >>> *From:* Tanaka, Satoko [mailto:sako-t@jp.fujitsu.com] >>> *Sent:* Wednesday, July 20, 2016 5:55 PM >>> *To:* Jonathan Avila <jon.avila@ssbbartgroup.com >>> <mailto:jon.avila@ssbbartgroup.com>>; WAI IG <w3c-wai-ig@w3.org >>> <mailto:w3c-wai-ig@w3.org>> >>> *Subject:* RE: Question: Key Operation of Dropdown menu >>> >>> Hi Jonathan, >>> >>> Thank you for summarizing the key points. It makes sense for me. >>> The last part of your comment, I cannot understand clearly the >>> situation of Safari on mobile. Do you mean mobile version of Safari >>> does not recognize keyboard connection, which means users cannot >>> operate the mobile Safari with keyboard? >>> It seems I should learn more about mobile accessibility. If you >>> would kindly explain more details, it would be highly appreciated. >>> Thanks in advance. >>> >>> Many thanks and kind regards, >>> Satoko >>> >>> *From:* Jonathan Avila [mailto:jon.avila@ssbbartgroup.com] >>> *Sent:* Wednesday, July 20, 2016 10:52 PM >>> *To:* WAI IG >>> *Subject:* RE: Question: Key Operation of Dropdown menu >>> >>> Satoko, in short it think what Bryan is getting at is it’s ok to >>> rely on arrow keys for desktop as long as the proper ARIA roles are >>> there that would allow these keys to be sent from desktop screen >>> readers and would be assumed by the user based on the appropriate >>> roles. If the appropriate roles are not used use of only arrow keys >>> would likely not be available to desktop screen reader users and may >>> not be apparent for use even if the user was an advanced screen >>> reader user. On mobile you will likely have a different situation >>> as some browsers like Safari do not pass keystrokes through from the >>> keyboard to the web page. >>> >>> Jonathan >>> >>> Jonathan Avila >>> Chief Accessibility Officer >>> SSB BART Group >>> jon.avila@ssbbartgroup.com <mailto:jon.avila@ssbbartgroup.com> >>> 703.637.8957 (Office) >>> >>> >>> >>> Visit us online: Website <http://www.ssbbartgroup.com/> | Twitter >>> <https://twitter.com/SSBBARTGroup> | Facebook >>> <https://www.facebook.com/ssbbartgroup> | Linkedin >>> <https://www.linkedin.com/company/355266?trk=tyah> | Blog >>> <http://www.ssbbartgroup.com/blog/> >>> >>> Check out our Digital Accessibility Webinars! >>> <http://www.ssbbartgroup.com/webinars/> >>> >>> >>> *From:* Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com] >>> *Sent:* Wednesday, July 20, 2016 2:04 AM >>> *To:* Tanaka, Satoko; WAI IG >>> *Subject:* RE: Question: Key Operation of Dropdown menu >>> >>> Hi, >>> In looking at the code shown on that page, it looks like the only >>> roles present are role=menubar and role=menu for the construct plus >>> embedded links with no roles. I’m unable to locate a working example >>> that shows this in action though both in IE11 and FF. Is this >>> present on the page? I can’t tell if the required child roles are >>> being added dynamically. >>> >>> The containers with role=menubar or role=menu require focusable >>> children with role=menuitem, or role=menuitemcheckbox, or >>> role=menuitemradio. All ARIA Menu constructs require owned children >>> with these roles. >>> E.G >>> http://whatsock.com/training/matrices/#menubar >>> and >>> http://whatsock.com/training/matrices/#menu >>> >>> To visually see these roles in action, try using Visual ARIA at >>> http://whatsock.com/training/matrices/visual-aria.htm >>> >>> When the bookmarklet is active and you are using the keyboard, any >>> elements that receive focus that don’t include these roles will be >>> shown in red font. >>> >>> The following Menubar example shows how keyboard functionality is >>> programmed according to spec, which also includes the requisite >>> keyboard information for relevant nodes: >>> https://github.com/accdc/aria-menubar >>> >>> Within the global.css file, the classes are set up >>> so that the required roles plus supporting attributes plus >>> focusability is clearly conveyed as implemented. >>> >>> Though ARIA 1.1 supports the use of aria-orientation to convey the >>> horizontal or vertical layout of role=menubar or role=menu now, >>> there is little to no support for conveying this to screen reader >>> users at present, so the above example includes logic to accomplish >>> this accessibly in the meantime. >>> >>> All the best, >>> Bryan >>> >>> >>> Bryan Garaventa >>> Accessibility Fellow >>> SSB BART Group, Inc. >>> bryan.garaventa@ssbbartgroup.com >>> <mailto:bryan.garaventa@ssbbartgroup.com> >>> 415.624.2709 (o) >>> www.SSBBartGroup.com <http://www.ssbbartgroup.com/> >>> >>> *From:* Tanaka, Satoko [mailto:sako-t@jp.fujitsu.com] >>> *Sent:* Tuesday, July 19, 2016 7:29 PM >>> *To:* WAI IG <w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org>> >>> *Subject:* Question: Key Operation of Dropdown menu >>> >>> Hi, >>> >>> I would like to ask a question about implementation of dropdown menu >>> created with WAI-ARIA. >>> >>> https://wet-boew.github.io/v4.0-ci/demos/menu/menu-en.html >>> In this example, there are three types of dropdown menus at the top >>> left corner. The labels are “Section 1”, “Section 2”, and “Section >>> 3”. A breadcrumbs menu is placed just below of the dropdown menu. >>> When tabbing this example page, the focus is on the menu of “Section >>> 1” first, and next, it moves to “Home” in the breadcrumbs rather >>> than to “Section 2” which is next to “Section 1”. >>> To move to “Section 2” from “Section 1”, the right arrow key must be >>> used, which means users can operate the dropdown menu with keyboard >>> as long as following a specific key operation. >>> >>> I’m wondering if this example is surely sufficient to WCAG 2.0. I >>> think it might have to provide an instruction of how to operate the >>> dropdown beforehand. >>> >>> My question is: >>> Is this key operation sufficient to WCAG 2.0? (the point is this >>> implementation does not depend on tab key operation) >>> In this case, is it necessary to describe how to operate the >>> dropdown menu with keyboard in order to meet SC of WCAG 2.0? >>> >>> I would highly appreciate, if someone kindly would give some good >>> advice to me. Thanks in advance. >>> >>> >>> Many thanks and kind regards, >>> Satoko >>> >> >> >> -- >> Christophe Strobbe >> Akademischer Mitarbeiter >> Responsive Media Experience Research Group (REMEX) >> Hochschule der Medien >> Nobelstraße 10 >> 70569 Stuttgart >> Tel. +49 711 8923 2749 >> >> “I drink tea and I know things.” >> Falsely attributed to Christophe Lannister. > -- Christophe Strobbe Akademischer Mitarbeiter Responsive Media Experience Research Group (REMEX) Hochschule der Medien Nobelstraße 10 70569 Stuttgart Tel. +49 711 8923 2749 “I drink tea and I know things.” Falsely attributed to Christophe Lannister.
Received on Thursday, 4 August 2016 13:12:46 UTC