W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2016

Re: multibyte content

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

This archive was generated by hypermail 2.3.1 : Thursday, 4 August 2016 13:12:46 UTC