I’m trying to enroll for apple developer programs but from Nigeria but my location is lock to United States and all my accounts detail are Nigeria,all my accounts details is Nigeria in my iCloud include my payment and shipping Adresses

https://www.icloud.com/iclouddrive/0e16-6zsa3ZnMkAsuLtdqiInA 不好意思，發現到之前給你們的意見中沒有附件，有時候勾選了的附件檔案，它沒有上載到，可能是我操作失誤。 另外，不確定是不是附件檔案限制或容量問題，我這邊有些影片上載後，選擇下載觀看時會提示失敗。有些沒有檔案。 我花了很多心機錄製反饋問題的影片，真的很抱歉，我重新將之前的所有內容發一次，改用 iCloud 空間發給你們看視頻反饋，這樣會更清楚明白遇到的問題，也方便你們在優化上參考。 謝謝你們，辛苦了。 希望可以重點關注。。 第一張。 第二章。 第三章。 重點關注者，三個優化 主题：关于无障碍体验优化的反馈与建议 尊敬的开发者团队： 您好！ 我是一名低视力用户，平时在使用各类应用时，会同时从视觉和屏幕朗读操作层面发现一些无障碍相关问题。 相比一般用户，我反馈的内容往往更全面、具体，也更能反映视障群体实际遇到的困难。 另外，我本人也有手部协调方面的问题，因此对于放大屏幕后所需操作手势所遇到的困难，我更能体会，也更加理解。尤其是返回（Back）操作是否便捷，对我来说尤为重要。 感谢你们一直以来的用心开发与持续维护。 我想特别说明一点：每一则意见背后，可能都代表着成千上万拥有相同困扰的使用者。但会主动花时间反馈问题的人，本来就是小众中的少数。团队有时可能会认为这些只是小众需求，不值得投入资源优化。然而很多时候，一个看似微小的逻辑调整，便能大幅改善全体视障用户的使用体验。 因此，诚挚希望你们能重视这类无障碍问题，多多参考视障团体的反馈，并在后续版本中进行修复与优化，让视障用户也能平等、顺畅地使用各项功能。 感谢你们一直以来的用心开发，期待你们的优化，谢谢！ [https://drive.google.com/file/d/1GL9cm8NbJfvOECpl0x08VRXQXQX0tACZ/view?usp=drivesdk)

Hello, I'm having a very hard time finding where any documentation or session or any WWDC related announcement related to the FaceTime API that was mentioned in this press release last month. https://www.apple.com/newsroom/2026/05/apple-unveils-new-accessibility-features-and-updates-with-apple-intelligence/ "For sign language interpretation app developers, a new API supports users in adding a human interpreter to an ongoing FaceTime video call." Can anyone please point me in the right direction? I have searched everywhere in Developer.app, documentation released during this WWDC, and here in the Forums and have yet to find anything.

I am unable to dismiss Voice Control Siri AI bubble when enabling Voice Control in iOS 27. Can someone from accessibility team provide guidance on how to dismiss without touching the screen in the activation flow? Siri bubble remains on screen... Thank you, and appreciate all the work you do. Voice Control is an amazing capability system wide.

Every new build of macOS 26 further breaks some part of text-to-speech or voice control. I have filed multiple bug reports on this, yet the situation gets worse, not better, with each new build. I am begging you to fix this! I am disabled and rely on these features to work. Accessibility in macOS is more than 50% of my reasons for choosing Macs over Windows. Here's some of what is currently broken: Speak announcements only works if the Samantha voice is selected. If other voices are selected either the announcements don't speak, or they default to the Samantha voice. This became broken with 26.1. Announce the time only works with some voices. I would like to use Australian English Siri 2 but with that voice selected it defaults to Samantha. This became broken with 26.4. With voice control enabled there are two menu bar icons. The blue voice control icon and an orange microphone "an application is accessing the microphone" icon. This orange icon started appearing with 26.3. For four years of macOS releases, the orange warning didn't apply to system services. And note that with voice control enabled on iOS there is no orange icon. It wastes valuable menu bar space and defeats its purpose. With that orange icon always being there I have no indication if a nefarious app starts recording me. This became broken with 26.3. Overlay shows numbers even when it is set to none. This has been broken since at least 14.0. I don't remember if it was broken in prior versions but it has been broken in every version since 14.0. The voice control control center widget is defective. If voice control is not in the menu bar (for example if I've said "Siri turn off voice control") using the control center widget to turn it on brings about the orange icon, but not the blue icon actually used for controlling voice control. If you do have the blue voice control icon and use control center to turn off voice control the blue icon stays but voice control is not enabled. This became broken in 26.0, was fixed in 26.2, broke again in 26.4. When using voice control to edit text (aka dictation mode) saying "go to the end of the line" invariably goes to the beginning of the line. Once in a blue moon it will go to the end, but there is no rhyme or reason and it's rare that it does. Since this bug was added it has worked correctly exactly twice. This became broken in 26.3 (possibly 26.4). I know I am missing some issues. Voice control and text-to-speech have new bugs with each new build of macOS 26. My main Mac is being repaired and once I get it back I'll be installing macOS 15 Sequoia on it because of these issues. These issues stop me from buying a new Mac because any new Mac will only run the broken macOS 26. I file bug reports on each build when I discover another new issue, but these reports seemingly go unread. I would suggest Apple get a focus group of disabled people together and do research into how we use macOS. Find what's broken and what works. And if Apple does this I would be glad to be a part of that group. My place, or yours. Accessibility at one time was something Apple was proud of. It was some Apple showed off. But now, I'm not so sure. It's starting to look like Apple doesn't care. I hope I'm wrong, and that Apple does care, so... Please, Apple. I am begging you. Fix broken Text-To-Speech and Voice Control!

Hello, In this press release from last month: https://www.apple.com/newsroom/2026/05/apple-unveils-new-accessibility-features-and-updates-with-apple-intelligence/ It indicates the following: "For sign language interpretation app developers, a new API supports users in adding a human interpreter to an ongoing FaceTime video call." I have looked over the WWDC26 sessions but have not been able to find any information on this new API. Can you point me in the right direction? Thank you!

I am testing out the new auto-generated subtitles feature on iOS 27 and tvOS 27. It works on iOS, but not on tvOS. Very same HLS videos. Anyone have any experience with auto-generated subtitles on tvOS 27? AFAICT, there is no special code needed to enable this feature for our apps, correct?

Feature Request: Native Acapela Voice Library Integration & Cross-Pipeline Voice Sharing Associated Feedback Feedback Assistant Ticket: FB23666342 1. The Core Proposal On behalf of the assistive technology and screen-reader community, I am requesting the native system-level integration of the comprehensive Acapela Voice Library into iOS and macOS. This library should be added as a native synthesizer tier alongside existing options like Eloquence. Additionally, we request cross-pipeline voice compatibility, allowing the Siri assistant to utilize configured VoiceOver voice assets, and allowing VoiceOver to utilize Expressive Siri neural models. 2. Structural UI Layout Concept To maintain system cleanliness while maximizing user choice, we propose grouping the Acapela catalog exactly like the current native Eloquence implementation: A main, expandable heading titled Acapela inside the Speech rotor settings. Under this heading, voices should be strictly categorized by global regional dialects (including English U.S., English UK, Australia, India, Scotland, and all other languages offered to AT vendors). This deployment must include all specialized character profiles (such as the Little Creature variant) and their pediatric/child voices catalog. 3. Addressing Ear Fatigue and Equity While parametric synthesizers are excellent for high-speed text scanning, extended multi-hour document audits cause severe cognitive ear fatigue due to compressed, robotic waveforms. Integrating the full Acapela catalog—including both 22kHz HQ (High Quality) profiles for natural reading stamina and 22kHz CO (Colibri/Compact) profiles for rapid responsiveness—allows blind and low-vision power users to pick their preferred acoustic texture. Natively licensing this library eliminates the unfair financial barrier of third-party lifetime licensing fees, creating true out-of-the-box system equity. If you want to check out my post on expressive Siri, see below. Link: https://developer.apple.com/forums/thread/834920

Hi everyone, With the initial rollout of the iOS 27 Beta, the advanced configuration sliders for the new, highly expressive Siri voice models are currently hidden/disabled on devices operating under an 8GB RAM threshold. While the local AFM 3 Core Advanced engine is memory-gated to 12GB+ hardware due to local footprint constraints, this creates a significant barrier for users who rely on next-generation vocal expressivity and fluid dictation features for accessibility. To address this, I have filed a formal feature request (FB23178983) asking Apple to route the expressive Siri framework through Private Cloud Compute (PCC) on 8GB devices (like the iPhone 15 Pro or base iPhone 16 models). By utilizing server-side rendering over secure, stateless cloud nodes, Apple could easily deliver these vital accessibility configurations without exhausting the local 8GB memory footprint. I’m curious if other accessibility testers and auditors on this board are looking for this exact routing path? If you or your users rely on advanced speech synthesis features and are currently locked out by the local RAM gate, please consider filing a duplicate request or adding your diagnostic logs to FB23178983 to help increase visibility with the Core Accessibility and Software Architecture triage teams. Looking forward to hearing your thoughts and experiences with the current voice-indexing behaviors on 8GB hardware!

Hi, guys, so some apps needed accessibility in order to do some things on my mac, (macos 27) yet the tab has disappeared from my privacy and security tab?

Feedback Assistant ID: FB24788469 (Cross-reference: Complementary to third-party TTS framework initiatives logged in FB23666342) Overview With the continued evolution of on-device machine learning and Apple Silicon's unified memory architecture, I propose that Apple evaluate expanding the native VoiceOver speech library in the upcoming iOS 28 cycle to incorporate lightweight, natural acoustic and neural voice models—specifically the profiles utilized across ChromeOS, Android, and CNET accessibility pipelines (including the natural Google Assistant voice profile). Hardware Feasibility & RAM Footprint • Demonstrated Efficiency on 8GB Systems: In real-world desktop testing across both an ASUS laptop and an HP laptop configured with 8GB of RAM, these voice profiles operate with near-instantaneous responsiveness, zero audio stutter, and negligible memory overhead. • Client-Side Execution Proof: In testing with NonVisual Desktop Access (NVDA)—an open-source Windows screen reader for blind and vision-impaired users—these voices run client-side using Google's WebAssembly (WASM) text-to-speech engine via background Chromium runtimes. Even during heavy UI tree navigation and multitasking, the 8GB systems run effortlessly without memory pressure warnings, UI latency, or process termination. • Viability Across 8GB & 12GB Apple Silicon: Apple Silicon devices leverage high-bandwidth unified memory and dedicated Neural Engine cores. Compiling or running these lightweight neural acoustic models via Core ML on all 8GB and 12GB devices running iOS 28—as well as future hardware generations—leaves substantial headroom for foreground apps without risking memory eviction. Technical & Practical Justification 1. Prosody and Auditory Fatigue: Modern neural synthesis captures natural cadence, warmth, and contextual phrasing, substantially reducing listening fatigue during multi-hour screen reading sessions compared to older formant or diphone synthesizers. 2. Deterministic On-Device Latency (Sub-50ms): Screen reader users require immediate auditory feedback when navigating character-by-character or word-by-word. Running these models locally on-device guarantees the sub-50ms response times essential for VoiceOver, with zero network latency and complete offline reliability. 3. Cross-Platform Continuity & Inter-Platform Synergy: Blind and low-vision users who switch between desktop environments (such as Windows with NVDA or ChromeOS) and iOS benefit greatly from vocal consistency across their workflows. Furthermore, given Apple's established collaboration with Google regarding foundational AI models, exploring speech asset licensing or compiling these lightweight voice packages into native iOS speech audio units represents a logical, accessible extension of existing synergy. Proposed Solution Provide downloadable, on-device voice packages for these high-efficiency neural and ChromeOS-style profiles directly within: Settings > Accessibility > VoiceOver > Speech > Voice in iOS 28. It would be greatly appreciated if I could get community feedback. If posting in a language other than English, I'll use Gemini to translate it into English and post the translation for English speakers as a reply to this post. Also, if you want to check out my posts on Acapela's voice library integration, and my Expressive Siri posts, check out the links below and give me your thoughts on them as well. This post will be cross-linked on those as well, creating a closed triangular circuit. Expressive Siri Link: https://developer.apple.com/forums/thread/834920 Acapela Voice Library Integration Link: https://developer.apple.com/forums/thread/837701

header 1 於無障礙旁白功能使用上，存在數項可優化項目。 第一，旁白內「偵測語言」開關關閉後，部分文字與符號會出現無法朗讀的情況，系統已設定繁體中文、簡體中文，問題仍然存在。此現象在iOS 26之前的版本並未發生。 第二，旁白朗讀功能有時會失效、沒有聲音，必須關閉旁白再重新啟用，才能恢復正常。 第三，旁白詳細程度設定中，雖已關閉新手提示，仍然會出現大量多餘播報內容。另外在輔助快取模式之下，部分旁白手勢無法正常運作，最常用由底部向上滑動返回主螢幕的手勢會失效。 懇請開發團隊優化中文介面旁白多餘播報內容，在已關閉新手提示的前提下，讓旁白播報更加清爽簡潔，並修復上述各項狀況。

Hello everyone, I am the developer of a macOS window management app called NeoTiler. I am currently optimizing it entirely for Apple Silicon using Swift. I am using the Accessibility API (AXUIElementSetAttributeValue) to resize windows. While it works flawlessly on Safari and native apps, I've noticed a slight animation stutter when resizing Electron-based apps like VS Code or Discord. Has anyone experienced this specific stutter with AX APIs on M-series chips? Are there any workaround flags I should pass? Thanks!

Hi 👋, I’m working on improving Full Keyboard Access support in an iOS app and would love to hear about your experience. When developing for keyboard navigation, what approach do you usually take for navigating between UI elements? Do you mainly use Tab/Ctrl+Tab, arrow keys, or a combination of both? I’ve already watched some WWDC sessions and Apple's docs on this topic: https://developer.apple.com/design/human-interface-guidelines/keyboards https://developer.apple.com/videos/play/wwdc2021/10120/ https://developer.apple.com/videos/play/wwdc2021/10260/ https://developer.apple.com/documentation/UIKit/navigating-an-app-s-user-interface-using-a-keyboard However, I’d appreciate any recommendations for useful resources, documentation, or things to be aware of when implementing keyboard accessibility. :🙏

I’m seeing a layout issue in SwiftUI on iOS 26 that only reproduces with specific Accessibility Motion settings. Steps to reproduce 1. Open Settings → Accessibility → Motion. 2. Enable Reduce Motion and Prefer Cross-Fade Transitions. 3. Launch an app with a SwiftUI TextField. 4. Tap the field to show the keyboard. 5. Dismiss the keyboard (tap outside, swipe down, etc.). Expected: After the keyboard is dismissed, the view’s bottom safe area / layout should return to normal. Actual: The view continues to reserve space equal to the keyboard height — as if the keyboard were still visible. UI anchored to the safe area remains shifted upward until the view is reloaded.

We format times in a localized way using the DateFormatter APIs.DateFormatter.localizedString(from: date, dateStyle: .none, timeStyle: .short)However if the result of this localization is say "22:00" VoiceOver just reads this out as "22". The VoiceOver user is given no indication that this numeric value is a time of the day.I've read online that one approach is to use DateComponentsFormatter and the spellOut unitsStyle e.g.let hourComponents = Calendar.current.dateComponents([.hour, .minute], from: date) cell.accessibilityLabel = DateComponentsFormatter.localizedString(from: hourComponents, unitsStyle: .spellOut)But again for a time "22:00" this reads out "22 hours". Sure if gives more context that this is related to time but it doesn't really indicate it is a time of the day i.e. it could be an interval (22 hours until something happens).We've trawled through the Apple documenation but we can't find anything that covers this.The best possible workaround we've found would be to force the accessibility label to be read out in 12 hour time i.e.let dateFormatter = DateFormatter() dateFormatter.setLocalizedDateFormatFromTemplate("hh:mm") accessibilityLabel =dateFormatter.string(from: date)that way it is clear to the user that it is a time of the day. Although this approach has the downside that ignores the user's preference of a 24 hour or 12 hour time display.The VoiceOver readout is handled perfectly in the Calendar app. It reads out "10 o'clock" and "22 hundred hours" in English and it is fully localized so for example it reads out "midi" for 12:00pm in French. It is possible that this is being done with private APIs though.So my question is, what is the recommended approach for formatting times for VoiceOver?

We have a password entry field with a "show password" button. The button effectively turns the "secure text entry" textfield into a non-secure text entry field allowing the user to view what they typed in. When VoiceOver is enabled, I am not including that button in the UI; it doesn't seem to make sense to me for the following reasons. If you properly test with the screen curtain, the functionality is useless. You don't see anything. I've tried to explain this to my accessibility team. It's also quite ridiculous to offer to show a blind user their password, I'm sure they'd love to see it, but they just can't. This would almost seem insulting as well. If by toggling that button, and turning a secure text entry into a non-secure text entry, now the app is literally speaking their password aloud. This seems like a security vulnerability to me. What if someone else overhears the password spoken aloud. The accessibility team is insisting that I need to include the "show password" button when VoiceOver is enabled. This is the response I received. "functionality should be the same for VI users as for sighted users. It may happen that a VI user wants to check what is typed into password field in order to correct mistakes". Again, I don't agree with that because functionality should not be the same. Functionality should be changed and altered as necessary to make the user experience as accessible as possible. And in this scenario, to me the functionality doesn't make sense at all in a VoiceOver setting. Any thoughts on this? Am I incorrect here? Are there benefits of including a "show password" button to a user utilizing VoiceOver? What should then the functionality be? Speak the password aloud? Thanks.

To the Apple iOS Development and Accessibility Teams, I am writing to formally request the addition of a native Lisu keyboard to iOS. As Apple continues to expand its global accessibility and language support, adding the Lisu language would bridge a significant communication gap for a vibrant and growing community. About the Lisu People: The Lisu are a Tibeto-Burman ethnic group with an estimated population of over 1.4 million. They traditionally inhabit the mountainous regions of Myanmar (Burma), Southwest China (particularly the Yunnan and Sichuan provinces), Thailand, and the Indian state of Arunachal Pradesh. They possess a rich cultural heritage, passed down through generations via extensive oral traditions, songs, and clan histories. The Lisu Language and Fraser Script: The Lisu language is officially supported by the Unicode Consortium. The writing system, known as the Fraser script, was developed in 1914 and was officially added to the Unicode Standard in Version 5.2. Unicode Reference: The Lisu block is designated at U+A4D0 – U+A4FF. Official Chart: Unicode [Lisu Chart (PDF)] https://www.unicode.org/charts/PDF/UA4D0.pdf Current Industry StandardsOther major operating systems have already recognized the importance of supporting the Lisu community: Microsoft Windows: Currently comes with a pre-installed Lisu keyboard, allowing users to type seamlessly out of the box. Android (Google): The default Gboard natively supports the Lisu keyboard, offering full mobile typing capabilities for Android users. Currently, iOS users who speak and write in Lisu must rely on third-party workarounds, which often lack the security, privacy, and seamless integration of Apple’s native keyboards. By implementing the Lisu keyboard, Apple would greatly enhance the iOS experience for over a million people, allowing them to communicate natively on their iPhones and iPads.Thank you for your time, consideration, and ongoing commitment to making technology accessible to everyone. I look forward to seeing Lisu supported in a future iOS update. Sincerely, Si_Gwa

I’m encountering what appears to be a synchronization issue between the numbers displayed by the iOS Voice Control overlay and the targets Voice Control actually activates. Environment: iPhone 13 Pro Max iOS 26.6.1 React Native 0.86.3 Expo SDK 57.0.17 Fabric/New Architecture enabled The issue occurs on a tutorial screen containing several interactive elements. After the screen changes or elements become enabled, disabled, mounted, or unmounted, Voice Control displays numbered overlays that do not correspond to its current command mapping. For example: Enable Voice Control and say “Show numbers.” Navigate to the affected tutorial step. The visible overlay places number 5 on an interactive square. Say “Tap 5.” Instead of activating that square, Voice Control activates the “Skip Tutorial” button. If I say “Hide numbers” followed by “Show numbers,” the newly displayed numbers reflect the actual command mapping. This demonstrates that: Voice Control’s internal target mapping has updated correctly. The visible number overlay has retained an older mapping. Saying a displayed number can therefore activate a completely different control. The behavior is reproducible in an older build that predates our Voice Control-specific tutorial changes, so it does not appear to have been caused by those changes. Setting the Voice Control overlay to “None” also does not resolve the underlying synchronization issue. I found a nearly identical cross-framework report in Flutter: https://github.com/flutter/flutter/issues/183821 That report describes the number overlay showing one mapping after button enabled-state changes while “Tap N” uses a different mapping. It remains open and does not appear to have a published workaround. Questions: Is this a known iOS Voice Control issue? Is there a supported way for an app to notify Voice Control that it must recalculate and redraw its numbered overlay? Would posting a UIAccessibility layout- or screen-changed notification help, or does Voice Control maintain this overlay independently? Are there particular patterns involving enabled/disabled or dynamically mounted accessibility elements that applications should avoid? Is there any way for an application to inspect the target associated with a Voice Control overlay number? My understanding is that these numbers are not exposed through a public API. This issue is especially concerning because the visible overlay instructs the user to say a number that can activate an unrelated control. In this example, it can activate “Skip Tutorial.” I can provide screen recordings and a minimal reproduction if helpful.

I would like to see an option to show live caption subtitles on Apple TV. So if I watch DAZN Sports it should generate subtitles via AI with settings enabled. This would give deaf people ability to watch sport with subtitles even it is not supported.