- From: Bryan Garaventa <bryan.garaventa@levelaccess.com>
- Date: Mon, 25 Feb 2019 22:57:15 +0000
- To: Tobias Bengfort <tobias.bengfort@posteo.de>, "w3c-wai-ig@w3.org" <w3c-wai-ig@w3.org>
Thanks, no problem. :) Actually this algorithm still includes the contributions you put into it about a year ago, it has just evolved into the fuller AccName project that it has become. Over the weekend, I updated the repo project to include more comprehensive guidance for pulling the code remotely into external projects, which also includes error handling to make catching and identifying unexpected issues easier to report and less disruptive if parsed in large scale recursive testing processes, like when testing hundreds of pages automatically. So now, the returned object now includes three properties, 'name', 'desc', and 'error', the last only being populated when a coding error is unexpectedly thrown. Since I'll be synchronizing the work on this code as AccName 1.2 is edited, it would be good if everybody uses the same algorithm, not just for synchronicity and the early catching of errors, but also to ensure that we all continue to file relevant bugs with browsers where expected and reproduceable results can be tested and reported with the same levels of accuracy in the future. This will also help to reduce misunderstandings between differing browsers since all should be reporting the same results equally in accordance with the algorithm. E.G. Issues can quickly be identified by comparing the output as generated on the test page, and comparing that with what the accessibility tree states the accessible name and description properties are for the same elements within different browsers. If they differ, then there is a definite problem, and bugs should be filed against the browsers that don't match. The more people who get involved in the process of doing this, the faster it will be to get emerging technologies on the same page in the future. And, as a simple point to illustrate the importance of this project, think of it this way, literally nothing virtual is or can be made accessible without a unified Name and Description at the core of it. So, the faster we get this done, the more accessible the web will become, in many cases automatically as these changes are rolled out. All the best, Bryan Bryan Garaventa Principal Accessibility Architect Level Access, Inc. Bryan.Garaventa@LevelAccess.com 415.624.2709 (o) www.LevelAccess.com -----Original Message----- From: Tobias Bengfort <tobias.bengfort@posteo.de> Sent: Saturday, February 23, 2019 4:05 AM To: w3c-wai-ig@w3.org Subject: Re: How to test the AccName algorithm dynamically using AccName Prototype CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Bryan, thanks for sharing this, it looks very useful! Incidentally I have worked on a very similar tool some time ago: https://xi.github.io/babelacc/ The main difference is that it will display the results from different implementations (including yours) which is probably only useful for library authors. Keeping these implementations up to date is tedious though (and I am probably not doing a good job with that). I will try to get a better understanding of the different usecases for these two tools. Maybe they can be merged or at least reference each other. But I did not have time to get into that just yet. tobias On 23/02/2019 11:51, Bryan Garaventa wrote: > Hi, > Since this comes up every now and again, usually with questions about > what is or not expected in the AccName computation, I wanted to pass > along the following live utility that helps to resolve this confusion, > available at > https://whatsock.github.io/w3c-alternative-text-computation/Editable%2 > 0Live%20Input%20AccName%20Test.html > > This works by pasting whatever code you want to test into the editable field at the end of the page and clicking the Paste and Test button. You need to make sure that the root node that you want to compute the Name and Description properties for includes id="test" to identify which element is meant to be designated as the root node in accordance with the AccName spec. Thanks goes to Todd Briley for writing the code for this. > > This also includes the feature where, if you paste focusable elements like links and buttons or form fields into this and render them using the Paste and Test button, you can use Tab and Shift+Tab to move focus between them and the AccName computation will automatically be displayed for the currently focusable element no matter what the ID is set to. Thank you David MacDonald for suggesting this. > > The live algorithm being used here is the same one that is run from > the W3C test case wiki to validate expected results, at > https://www.w3.org/wiki/AccName_1.1_Testable_Statements > > As I continue working on edits for AccName 1.2, I will ensure to keep this live algorithm up to date with the latest updates as we hammer out the details of what AccName is meant to convey. > http://www.w3.org/TR/accname-1.1/ > > Visual ARIA, as referenced within the same page, also includes the same AccName algorithm, both of which will always be synchronized. > > Since crowd sourcing is one of the most effective ways of identifying > bugs, the more people who use this the better to make sure we haven't > missed anything. Please pass along any issues and if found as part of > the AccName Prototype, file them against the archive for this at > https://github.com/WhatSock/w3c-alternative-text-computation > Otherwise, if uncertain, file them against the AccName spec at > https://github.com/w3c/accname/ (Please review the currently open > issues to be certain the issue hasn't already been reported for the > 1.2 milestone) > > All the best, > Bryan > > > Bryan Garaventa > Principal Accessibility Architect > Level Access, Inc. > Bryan.Garaventa@LevelAccess.com > 415.624.2709 (o) > www.LevelAccess.com > > -----Original Message----- > From: WebAIM-Forum <webaim-forum-bounces@list.webaim.org> On Behalf Of > Birkir R. Gunnarsson > Sent: Friday, February 22, 2019 5:41 AM > To: WebAIM Discussion List <webaim-forum@list.webaim.org> > Subject: Re: [WebAIM] aria-label vs alt text on linked images > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > According to the accessible name and description computation spec the alt text on an image inside a link with aria-label should not be announced. > aria-label overrides native HTML labeling (for a link with an image inside it that has an alt text, the alt text would be the native labeling in this instance). > So if you think of this as a single entity the aria-label should always be announced and the alt text ignored. > But if you think of this as two separate entities, the image separate from the link, then it makes sense that if you navigate to the image, as opposed to the link, that some screen readers may announce the alt text for the image. > I think a link with an image inside it should be treated as a single entity, but I am not sure if that interpretation is correct. > Authors can solve this dilemma by using one or the other, not both. > According to the spec, the alt text should be ignored in this situation. > > > > On 2/22/19, Isabel Holdsworth <lynn.holdsworth@gmail.com> wrote: >> Hi Patrick, >> >> It would be good if you could take an either-or approach and use only >> the alt or only the aria-label attribute. I'd personally go for the >> alt attribute on the image, as these have been kicking around since >> Methuselah was a sprog and are treated in much the same way by most >> browsers and screenreaders. >> >> Cheers, Isabel >> >> On 04/01/2019, Léonie Watson <tink@tink.uk> wrote: >>> The problem seems to be with specific browser and screen reader >>> combinations, coupled with the mode of interaction. A very quick >>> test using this example: >>> >>> <a href="https://example.com" aria-label="Example website"><img >>> src="example.png" alt="Example logo"></a> >>> >>> >>> With Jaws 2019 in Chrome, Firefox, and Edge; with NVDA in Chrome, >>> Firefox, edge, and IE; with VoiceOver in Safari on iOS; the -label >>> is announced however you focus on the link. >>> >>> With Jaws in IE, the alt text is announced however you focus on the >>> link; with VoiceOver in Safari on MacOS, the alt is announced if you >>> arrow onto the link, and the -label is announced if you use any >>> other mode of interaction. >>> >>> >>> This was a very quick test on a single instance of each combination, >>> so please treat the results on that basis! >>> >>> >>> Léonie. >>> On 04/01/2019 15:30, Patrick Follmann wrote: >>>> Thanks Steve, I appreciate your response and understand the >>>> question about why both are used. >>>> >>>> It was mostly just an experiment based on client feedback -- and we >>>> know that those of us who only heard the aria-label are using >>>> default settings on our screen reader software and the three of us >>>> have the same browser versions and we are all tabbing through the >>>> page to hear what is announced. >>>> I am not sure about the colleague who is hearing only alt text >>>> though, except I know he is using the same screen reader versions. >>>> >>>> Patrick >>>> >>>> >>>> >>>> On Fri, Jan 4, 2019 at 10:18 AM Steve Green >>>> <steve.green@testpartners.co.uk> >>>> wrote: >>>> >>>>> There are lots of reasons why this might happen, such as: >>>>> >>>>> Different methods of navigation, such as tabbing or virtual cursor. >>>>> Different behaviours in different versions of the same assistive >>>>> technology product. These are not usually mentioned in the release >>>>> notes so you only find them by experimentation. >>>>> Different behaviours between browsers. >>>>> Different configuration settings in the assistive technology. >>>>> >>>>> Why do you have an "aria-label" attribute if the images have "alt" >>>>> attributes? >>>>> >>>>> Steve Green >>>>> Managing Director >>>>> Test Partners Ltd >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: WebAIM-Forum <webaim-forum-bounces@list.webaim.org> On >>>>> Behalf Of Patrick Follmann >>>>> Sent: 04 January 2019 15:09 >>>>> To: WebAIM Discussion List <webaim-forum@list.webaim.org> >>>>> Subject: [WebAIM] aria-label vs alt text on linked images >>>>> >>>>> Hello, >>>>> >>>>> Some colleagues and I are getting different results when using >>>>> screen readers with linked image that have no link text but have >>>>> an aria-label attribute in the a tag and an alt attribute in the >>>>> img tag. (tabbing to the >>>>> image) >>>>> >>>>> One colleague is hearing screen readers (VoiceOver, JAWS and NVDA >>>>> with various browsers) read only the alt text. The rest of us are >>>>> hearing only the aria-label announced. >>>>> >>>>> What is expected behavior and why might we be getting different results? >>>>> We'd like to solve the mystery so we don't have conflicting >>>>> results in the future. >>>>> >>>>> Thank you, >>>>> >>>>> Patrick >>>>> _______________________________________________ >>>>> To manage your subscription, visit http://list.webaim.org/ List >>>>> archives at http://webaim.org/discussion/archives >>>>> Address list messages to webaim-forum@list.webaim.org >>>>> _______________________________________________ >>>>> To manage your subscription, visit http://list.webaim.org/ List >>>>> archives at http://webaim.org/discussion/archives >>>>> Address list messages to webaim-forum@list.webaim.org >>>>> >>>> _______________________________________________ >>>> To manage your subscription, visit http://list.webaim.org/ List >>>> archives at http://webaim.org/discussion/archives >>>> Address list messages to webaim-forum@list.webaim.org >>>> >>> >>> -- >>> @LeonieWatson tink.uk Carpe diem >>> _______________________________________________ >>> To manage your subscription, visit http://list.webaim.org/ List >>> archives at http://webaim.org/discussion/archives >>> Address list messages to webaim-forum@list.webaim.org >>> >> _______________________________________________ >> To manage your subscription, visit http://list.webaim.org/ List >> archives at http://webaim.org/discussion/archives >> Address list messages to webaim-forum@list.webaim.org >> > > > -- > Work hard. Have fun. Make history. > _______________________________________________ > To manage your subscription, visit http://list.webaim.org/ List > archives at http://webaim.org/discussion/archives > Address list messages to webaim-forum@list.webaim.org >
Received on Monday, 25 February 2019 22:57:44 UTC