Re: ACTION-1442: Draft spec text for aria-current and aria-currentfor

Not sure. I even think I like aria-current since potentially it can be used
for a wider range of use cases like in case of calendars. What would be
worth I think is to collect the use cases everybody keeps in mind, and see
what name(semantic) tailors them better.

On Wed, Nov 19, 2014 at 3:06 PM, Matthew King <mattking@us.ibm.com> wrote:

> Alex, do you have an idea for making it less confusing? I still think
> displayed would be less confusing to a new user than current, but we are
> all obviously guessing.
>
> A verbose screen reader could say: "Link page 1, this page is currently
> displayed". Screen readers have the option of doing whatever they like.
> But, at this point, I am mostly thinking about authors and screen reader
> vendors and what they are likely to do.
>
> Matt King
> IBM Senior Technical Staff Member
> I/T Chief Accessibility Strategist
> IBM BT/CIO - Global Workforce and Web Process Enablement
> Phone: (503) 578-2329, Tie line: 731-7398
> mattking@us.ibm.com
>
>
>
> From:        Alexander Surkov <surkov.alexander@gmail.com>
> To:        Matthew King/Fishkill/IBM@IBMUS,
> Cc:        Joseph Scheuhammer <clown@alum.mit.edu>, "W3C WAI Protocols &
> Formats" <public-pfwg@w3.org>
> Date:        11/19/2014 11:59 AM
> Subject:        Re: ACTION-1442: Draft spec text for aria-current and
> aria-currentfor
> ------------------------------
>
>
>
> Oh, so displayed is in relation to the document/page/panel the current
> link/tab/etc is for. This makes sense but might be found also confusing I
> guess.
>
> On Wed, Nov 19, 2014 at 2:52 PM, Matthew King <*mattking@us.ibm.com*
> <mattking@us.ibm.com>> wrote:
> Alex wrote:
> > displayed sounds like visible with me, something on the screen
>
> Matthew King <*mattking@us.ibm.com* <mattking@us.ibm.com>> wrote:
> > Yes, that is the understanding we want to convey, right?
>
> Alex wrote:
> > Not sure. What about navigation links when all of them are presented and
> only one of them is "current"?
>
> Matt's response:
> Use case: You have a list of 5 nav links ("page 1", "page 2", ... "page
> 5") in a nav element. The  link for "page 1" has been activated so that
> page is displayed in the main content. The anchor for "page 1" has
> aria-displayed="true". When reading the content of the nav element, the
> screen reader user would hear something like "Link page 1 displayed".
>
> Matt King
> IBM Senior Technical Staff Member
> I/T Chief Accessibility Strategist
> IBM BT/CIO - Global Workforce and Web Process Enablement
> Phone: *(503) 578-2329* <%28503%29%20578-2329>, Tie line: 731-7398
> *mattking@us.ibm.com* <mattking@us.ibm.com>
>
>
>
> From:        Alexander Surkov <*surkov.alexander@gmail.com*
> <surkov.alexander@gmail.com>>
> To:        Matthew King/Fishkill/IBM@IBMUS,
> Cc:        Joseph Scheuhammer <*clown@alum.mit.edu* <clown@alum.mit.edu>>,
> "W3C WAI Protocols & Formats" <*public-pfwg@w3.org* <public-pfwg@w3.org>>
> Date:        11/19/2014 11:28 AM
> Subject:        Re: ACTION-1442: Draft spec text for aria-current and
> aria-currentfor
>  ------------------------------
>
>
>
> Not sure. What about navigation links when all of them are presented and
> only one of them is "current"?
>
> On Wed, Nov 19, 2014 at 2:15 PM, Matthew King <*mattking@us.ibm.com*
> <mattking@us.ibm.com>> wrote:
> Alex wrote:
> > displayed sounds like visible with me, something on the screen
>
> Yes, that is the understanding we want to convey, right?
>
> Matt King
> IBM Senior Technical Staff Member
> I/T Chief Accessibility Strategist
> IBM BT/CIO - Global Workforce and Web Process Enablement
> Phone: *(503) 578-2329* <%28503%29%20578-2329>, Tie line: 731-7398
> *mattking@us.ibm.com* <mattking@us.ibm.com>
>
>
>
> From:        Alexander Surkov <*surkov.alexander@gmail.com*
> <surkov.alexander@gmail.com>>
> To:        Matthew King/Fishkill/IBM@IBMUS,
> Cc:        Joseph Scheuhammer <*clown@alum.mit.edu* <clown@alum.mit.edu>>,
> "W3C WAI Protocols & Formats" <*public-pfwg@w3.org* <public-pfwg@w3.org>>
> Date:        11/19/2014 11:12 AM
> Subject:        Re: ACTION-1442: Draft spec text for aria-current and
> aria-currentfor
>  ------------------------------
>
>
>
> displayed sounds like visible with me, something on the screen
>
> On Wed, Nov 19, 2014 at 1:57 PM, Matthew King <*mattking@us.ibm.com*
> <mattking@us.ibm.com>> wrote:
> After further work and thought, I am still questioning the name.
> Couldn't we create greater clarity and understanding by calling this
> aria-displayed?
>
> 1. When it comes to screen reader users, if I heard "displayed", I think I
> would more easily figure out what it means.
>
> 2. When it comes to authors, I would think it would be much easier to
> understand the difference between displayed and selected vs current and
> selected.
>
> 3. I also would not be surprised if "displayed" resulted in more accurate
> translations by vendors of non-english screen readers.
>
> I understand there is apossibility it would more narrowly scope its
> application, but that could be a really good thing when it comes to
> creating clarity. However, I have not yet heard of a use case where the
> meaning was not synonomous with "displayed".
>
> Matt King
> IBM Senior Technical Staff Member
> I/T Chief Accessibility Strategist
> IBM BT/CIO - Global Workforce and Web Process Enablement
> Phone: *(503) 578-2329* <%28503%29%20578-2329>, Tie line: 731-7398
> *mattking@us.ibm.com* <mattking@us.ibm.com>
>
>
>
> From:        Matthew King/Fishkill/IBM@IBMUS
> To:        Joseph Scheuhammer <*clown@alum.mit.edu* <clown@alum.mit.edu>>,
>
> Cc:        *public-pfwg@w3.org* <public-pfwg@w3.org>
> Date:        11/19/2014 10:22 AM
> Subject:        Re: ACTION-1442: Draft spec text for aria-current and
> aria-currentfor
>  ------------------------------
>
>
>
> Revisions to yesterday's proposal:
>
> 1. Clarified that false and undefined are equivalent and false is the
> default.
>
> 2. Clarified that UA should not expose and AT should not convey false or
> undefined.
>
> In the following text, phrases in square brackets are intended to be
> links.
>
> Aria-current attribute
>
> Indicates an element represents the current item within a container or set
> of related elements.
>
> The aria-current attribute indicates whether an element represents what is
> current (true), or not current (false). If the aria-current attribute is
> false or undefined, User Agents SHOULD NOT expose the aria-current state of
> an element, and assistive technologies SHOULD NOT convey it.
>
> The aria-current attribute is used when one of the elements in a set of
> related elements has a visual style different from other members in the set
> to indicate that the element identifies what is current. For example, it
> can be used to indicate which [link] in a set of [navigation] links is
> visually styled to indicate that it is the link for the currently displayed
> page. Similarly, it can be used to indicate which step in a [list] of
> wizard steps is visually styled to inform the user that the currently
> displayed wizard content is for that step.
>
> Note:
> When applied to an element contained in a widget that supports selection,
> the meaning of aria-current is different from the meaning of
> [aria-selected]. Authors should not use aria-current in lieu of
> aria-selected and should avoid using aria-current in circumstances where
> the meaning of aria-current would be the same as aria-selected. For
> example, in a single-select [tablist] where the selected [tab] element
> corresponds to the displayed tabpanel, aria-current is unnecessary.
> However, if the selected state of a tab is used to indicate which tab is
> selected for an action, such as move, delete, or display (make current),
> then aria-current should be used to indicate which tab represents the
> currently displayed tabpanel. Examples that further explain how to use
> aria-current and aria-selected are available in the [WAI-ARIA Authoring
> Practices].
>
> Characteristics of aria-current
>
> Used in roles: All elements of the base markup.
>
> Value: true/false
>
> Values of aria-current
>
> true: The element is current.
> false (default): The element is not current
>
> Matt King
> IBM Senior Technical Staff Member
> I/T Chief Accessibility Strategist
> IBM BT/CIO - Global Workforce and Web Process Enablement
> Phone: *(503) 578-2329* <%28503%29%20578-2329>, Tie line: 731-7398
> *mattking@us.ibm.com* <mattking@us.ibm.com>
>
>
>
> From:        Joseph Scheuhammer <*clown@alum.mit.edu* <clown@alum.mit.edu>
> >
> To:        Matthew King/Fishkill/IBM@IBMUS, Joseph Scheuhammer <
> *clown@alum.mit.edu* <clown@alum.mit.edu>>,
> Cc:        *public-pfwg@w3.org* <public-pfwg@w3.org>
> Date:        11/19/2014 09:58 AM
> Subject:        Re: ACTION-1442: Draft spec text for aria-current and
> aria-currentfor
>  ------------------------------
>
>
>
> LĂ©onie, Matt,
>
> Thanks for your clarifications.
>
> > So, what is the best way to write the text so the undefine/false
> > equivalency is clear?
>
> For the "Values" table, how about:
>
> "false (default):  The element is not current.
> true: The element is current."
>
> I'm following the style of the value tables for other boolean aria-*
> attributes. For example, see the table for aria-disabled
> (*http://rawgit.com/w3c/aria/master/aria/aria.html#aria-disabled*
> <http://rawgit.com/w3c/aria/master/aria/aria.html#aria-disabled>).
>
> Similarly, for the "Value" entry in the "Characteristics" table:
>
> "Value: true/false"
>
> Also, given that "conveyed by User Agents" has to do with the
> accessibility API, I suggest this re-wording:
>
> "If the aria-current attribute is false or undefined, User Agents SHOULD
> NOT expose the aria-current state of an element, and assistive
> technologies SHOULD NOT convey it."
>
> Hope that helps.
>
> --
> ;;;;joseph.
>
> 'Array(16).join("wat" - 1) + " Batman!"'
>           - G. Bernhardt -
>
>
>
>
>
>
>

Received on Wednesday, 19 November 2014 20:29:25 UTC