Re: Proposal and Justification for ARIA 1.2 (Was: text role removal)

+1 to Rich.

On 8/12/16, Richard Schwerdtfeger <richschwer@gmail.com> wrote:
> I am thinking this needs to be 1.2 vs. the graphics module. This is going to
> take a lot more discussion and we are trying to lock down SVG graphics as
> well as ARIA 1.1.
>
> I would much rather the team work on the test suite and the existing work
> off our plate. James has made his case for an ARIA 1.2. The group can vote
> on that later after we have spoken with the TAG and Web Components.
>
> Rich
>
>
>> On Aug 12, 2016, at 2:21 PM, Matt King <a11ythinker@gmail.com> wrote:
>>
>> Screen reader users care about fonts!!!!!!!!!!!!!!
>>   <>
>> Matt
>>
>> From: White, Jason J [mailto:jjwhite@ets.org]
>> Sent: Friday, August 12, 2016 8:47 AM
>> To: Fred Esch <fesch@us.ibm.com>; Matt King <a11ythinker@gmail.com>
>> Cc: 'Amelia Bellamy-Royds' <amelia.bellamy.royds@gmail.com>; 'Steven
>> Faulkner' <faulkner.steve@gmail.com>; 'James Craig' <jcraig@apple.com>;
>> 'Joanmarie Diggs' <jdiggs@igalia.com>; 'Michiel Bijl' <michiel@agosto.nl>;
>> 'Accessible Rich Internet Applications Working Group'
>> <public-aria@w3.org>; 'Richard Schwerdtfeger' <richschwer@gmail.com>
>> Subject: RE: Proposal and Justification for ARIA 1.2 (Was: text role
>> removal)
>>
>>
>>
>> From: Fred Esch [mailto:fesch@us.ibm.com <mailto:fesch@us.ibm.com>]
>> Sent: Friday, August 12, 2016 11:32 AM
>>
>> I disagree with this statement at least for SVG.
>> Regardless of how the graphic is drawn, we should never hide the fact that
>> it is a graphic. That information is very important.
>>
>> Some SVG authoring tools generate path elements for everything instead of
>> using the full suite of drawing primitives; and that is just how they
>> work. In these cases, there is no attempt by the author to use a symbol
>> for text, nor is the author avoiding using the text element. In these
>> cases, telling a user that the text comes from a graphic/path (or n-paths)
>> is not beneficial, nor does it covey what a sighted user sees.
>>
>> [Jason] I’ve been thinking about this, and I can think of very few
>> situations in which this information would be of benefit to the user.
>> There might be a stylized font on the page that might be referred to in a
>> conversation between a screen reader user and a colleague, but what is
>> desirable in that case is proper font identification, not merely an
>> indication that the text (and it could be the entire text within a given
>> construct) is rendered as a graphic.
>>
>>
>> In some cases, like when the author chooses a unusual font that is
>> unlikely to be on a user's machine, turning text into a path may be the
>> only way to ensure the visual appearance of the text is maintained on the
>> user's machine. Again, because it is captured as a path element is not
>> important to any user, sighted on not.
>>
>> [Jason] Agreed, but having the font information could sometimes be useful.
>> Maybe that’s an issue for the CSS Accessibility Task Force, especially if
>> they’re planning to disclose a subset of CSS properties to accessibility
>> APIs.
>>
>>
>>
>>
>> This e-mail and any files transmitted with it may contain privileged or
>> confidential information. It is solely for use by the individual for whom
>> it is intended, even if addressed incorrectly. If you received this e-mail
>> in error, please notify the sender; do not disclose, copy, distribute, or
>> take any action in reliance on the contents of this information; and
>> delete it from your system. Any other use of this e-mail is prohibited.
>>
>>
>> Thank you for your compliance.
>>
>
>


-- 
Birkir Gunnarsson, CPACC
Senior Accessibility Subject Matter Expert | Deque Systems
2121 Cooperative Way, Suite 210
Herndon, VA, 20171

Ph: (919) 607-27 53
Twitter: @birkir_gun

Received on Friday, 12 August 2016 19:35:34 UTC