This may sound like a bit of an odd question, but this was what I was told this morning by one of our Accessibility managers. This past June at WWDC, I scheduled a lab session with Apple's accessibility folks for a review. I had the pleasure of working with Ryan who helped give the great VoiceOver Testing Talk from WWDC 2018. I believe I've worked with him before in the labs, but regardless, no matter who I meet with in the Accessibility Labs they always provide me with some new nugget of information that I learn, no matter how well versed I might think I am in Accessibility. After the labs, I made all the changes that Ryan suggested and also told other developers on my team of what I was taught. In our app we provide various forms, and each field component that appears in the form has a header text which we apply a header trait to. This allows for the use of a Header Rotor to quickly navigate between all the questions in the form, say if a user wants to return to a previous field etc. I even suggested we should take the time to provide a custom rotor that would allow users to navigate to fields that may be in an error state. If say the user submits the form, and the responses are validated, if 1 or multiple fields be in error we should have a rotor to allow the user to navigate directly to those fields. They may not be able to see the Red text / red outlines of those fields. This morning, I was told that I needed to undo that. That our headerLabel properties should not be marked with the UIAccessibilityTrait.header trait. When I stated that it makes navigation of the form much easier via the Headers Rotor, I was told by the Accessibility Manager this is not the case. I have the MS Teams transcript in front of me, which reads as follows (give or take a few transcript errors) So I went ahead and I just double checked with two of my friends, who are blind and for them on their end, they both said that they would not actually use that, and could add more complexity, because they have—in addition to being blind—but there's also mobility limitations. So they actually can't even use the Rotor at all. They only can use the swipes. Does this make sense to anyone, because it doesn't to me? Thoughts on this?

When would it be a good idea to utilize numbered lists with VoiceOver accessibility. As an example, for tab bars it will read about "2 of 5". In speaking with an Accessibility engineer at WWDC this year, the said that its good practice, but we ran out of time in the call to dig further deeper. When or how do you know when you should read out the item count "2 of 5". It makes sense to me in say a tab group or a chip group, but I don't see it being good in say potentially a UITableView with potentially a various number of sections of which each section itself can include multiple cells. I've had trouble finding additional guidance on this topic, if anyone can provide recommendations or their thoughts, that would be great.

I am looking to support rendering markdown text while adding corporate branding styles (typography and colors for headers specified by the design team, etc). All was going well until I encountered Ordered List and began seeing some unexpected behavior. Lets take for example some sample markdown as shown below. let sampleMarkdown: String = """ # Ordered List Test This is some sample markdown used to test ordered lists. 1. Line item one of a sample markdown ordered list. 2. This is the second line item of a sample markdown ordered list. 3. And finally, the third line item of a sample markdown ordered list. """ Now, let's say for each item in the ordered list, I would like to assign a random foreground color to the text. This is straightforward as I can loop over the runs of an attributed string and should I encounter an intentType.kind of .orderedList I can apply the random foreground color as so with clode along the lines of such: for run in pulseAttributedString.runs { if let presentationIntent = run.presentationIntent { for intentType in presentationIntent.components { switch intentType.kind { case .orderedList: let colors: [UIColor] = [.green, .systemPink, ...] container[AttributeScopes.UIKitAttributes.ForegroundColorAttribute.self] = colors.randomElement() } } } } Upon setting the random foreground color to the attribute container, and running in the Simulator you can see the following output. This is very much close to what I'd expect although frustratingly the parser seemed to have stripped out the 1. 2. etc. I'm not sure what the reasoning for that is, or why the .orderedList does not have an associated value representing the index of the line item in the list, similar to how case header(level: Int) includes an associated value for header level. Upon closer inspection, I also see that there is another presentation intent kind of case listItem(ordinal: Int). When I add a case in my switch statement for listItem I see it too is included within the presentation intent components. With that said, I need to restore the 1., 2. etc, would I use case listItem(ordinal: Int) or .orderedList. And what would be the difference between the two? Would someone be able to explain that to me since the documentation for listemItem seems to make no effort to do so. This now leads me to the next issue I was encountering where if I then add emphasis to some words within the ordered list, essentially the same sample markdown above but with emphais on the word one and second: let sampleMarkdown: String = """ # Ordered List Test This is some sample markdown used to test ordered lists. 1. Line item *one* of a sample markdown ordered list. 2. This is the *second* line item of a sample markdown ordered list. 3. And finally, the third line item of a sample markdown ordered list. """ I now encounter the unexpected behavior where the words that received the emphasis also have a paragraph attribute associated with them, as shown in the screenshot below. I can log the presentationIntent and confirm that in my console that there are now presentation intent components for listItem, orderedList and now a paragraph. [paragraph (id 5), listItem 1 (id 4), orderedList (id 3)] So now it appears that in addition to having to restore and insert the 1., 2. etc, to the line items, but now I also need to make sure I strip out the added paragraph intent that gets added to a piece of text has emphaisis within an orderedList line item? This doesn't seem to make sense to me, am I doing something wrong?

I am seeing the following log in the console in Xcode Version 15.0.1 (15A507): Cannot use inflection engine (Checking that the token is the correct type): I am able to reproduce the issue using Apple's own sample code, "Building a Localized Food-Ordering App" associated with WWDC21 Session 10109: What's New In Foundation, simply by building and running the sample code. That log message immediately appears a few times in the console when running that sample project. I'm assuming given it is happening in Apple's own sample project, that this is merely console noise and basically something out of my control.

I'm seeing a strange issue in which my @IBDesignable class fail to render in Interface Builder unless I make a change to the underlying class file. To elaborate on what I mean by that, Create a subclass of UIButton and mark the class as @IBDesignable Add some @IBInspectable properties. Switch over to Interface Builder, go to the Library and drag an instance of a Button onto your Interface Builder canvas. Go to the Identity Inspector and change the class type from UIButton to your custom UIButton subclass. Go back to the Attributes Inspector. At this point, I do see all my @IBInspectable properties in the Attributes Inspector, and Interface Builder properly puts my custom class name above my defined inspectable properties. Everything looks normal except for the fact that the UI above my Inspectable that typically reads "Designables Up to date" does not show at all. I then proceed to change and modify the Inspectable properties only to see that the button in the canvas does not update or change at all. At this point, I go back to my class file, and make a modification. Any modification at all, even just adding a single space to a comment, and when I go back to Interface Builder, everything is working. I see the "Designables Up to date" UI showing, my button is displaying with my custom styling, etc. If I interact with, and make changes to my Inspectable properties in the Attributes Inspector, my button also properly updates in real time. While an annoyance during the development process, I do see this becoming a bit of more significant issue given the fact that the components I am building into a Framework are to be distributed to 3rd party developers in the form of XCFramework binary in a Swift Package. A third party developer won't be able to say, go to the class file and make a modification, nor would I want them to. The only other work around I found is after changing the class type to your custom @IBDesignable class, to then just quit and reboot Xcode. And when after relaunching the @IBDesignable appears and works correctly. Obviously, I don't want to add to my documentation to reboot Xcode after dragging a UI component to your canvas. I've never seen this issue before, has anyone else seen anything like this? I am currently running Xcode 13.4.1 (13F100), still haven't had a chance to update to the latest Xcode. I will also try upgrading later this afternoon to the latest Xcode 14 release but I'm not seeing anything in the Release Notes that might indicate anything that would address this issue if it had been previously identified.